use leasedb (not crawler) to figure out how many shares you have and how many bytes

[zooko]

In current trunk, there is a "BucketCountingCrawler" whose job it is to count up how many shares are stored.

I propose that this be replaced by using the leasedb to count files (a simple SQL COUNT query!), and at the same time to extend the storage server's abilities by letting it be able to add up the aggregate sizes of things as well as their number.

This is part of an "overarching ticket" to eliminate most uses of crawler — ticket #1834.

[zooko]

The part about reporting total space usage would be very useful for customers of LeastAuthority.com (who pay per byte), among others.

[davidsarah]

+1.

[zooko]

Using leasedb this way would facilitate solving #671 — bring back sizelimit (i.e. max consumed, not min free).

[zooko]

Using leasedb this way would facilitate solving #940.

[davidsarah]

The most basic form of the 'total used space' query is

SELECT SUM(`used_space`) FROM `shares`

How much account-specific information should we add? At the moment, there are only two accounts -- anonymous and starter -- but that is already enough to introduce the complication that more than one account can hold a lease on the same share, so the query above is not equivalent to

SELECT SUM(`used_space`) FROM `shares` s JOIN `leases` l
       ON (s.`storage_index` = l.`storage_index` AND s.`shnum` = l.`shnum`)

since that can count space for a share more than once.

[davidsarah]

This query solves the above problem, giving the total number of leased shares and the total space used by leased shares:

SELECT COUNT(*), SUM(`used_space`)
  FROM (SELECT `used_space`
          FROM `shares` s JOIN `leases` l
          ON (s.`storage_index` = l.`storage_index` AND s.`shnum` = l.`shnum`)
          GROUP BY s.`storage_index`, s.`shnum`)

(Any WHERE clause can be added to the inner SELECT to pick leases that satisfy certain criteria.)

And this gives the number of shares and total used space leased by each account, sorted beginning with the one that is using most space:

SELECT `account_id`, COUNT(*), SUM(`used_space`)
  FROM `leases` l LEFT JOIN `shares` s
  ON (l.`storage_index` = s.`storage_index` AND l.`shnum` = s.`shnum`)
  GROUP BY `account_id` ORDER BY SUM(`used_space`) DESC

[zooko]

After talking with markberger today, I realized that #1818 is the ticket to merge leasedb into trunk, and #1819 is the superceding ticket to merge leasedb+cloud-backend into trunk.

[markberger]

Here is a patch for this ticket: ​https://github.com/markberger/tahoe-lafs/tree/1836-use-leasedb-for-share-count

[daira]

Reviewed, but I think this doesn't remove the BucketCrawler yet.

[daira]

Removed review-needed until BucketCountingCrawlectomy is complete.

[markberger]

All of the BucketCountingCrawler code has been removed and tests have been added to the branch.

[daira]

Reviewing.

[remyroy]

Diara, did you review this one past comment 16. Is this still in need of a review?

[remyroy]

I'll do another pass at the code review for this one.

[daira]

I appear to have dropped the ball on this one after comment:16. Yes, it's still in need of review.

[remyroy]

Review of ​https://github.com/markberger/tahoe-lafs/tree/1836-use-leasedb-for-share-count :

Good job with this change. There are a few small things that I found.

I could not run the full test suite. It might be because this branch was made on a somewhat old version of tahoe-lafs. There are a bunch of "exceptions.ImportError: cannot import name HTTPConnectionPool" in the tests. If you could merge your branch with the latest trunk version, it might solve this.

In src/allmydata/web/storage.py, it seems like there are still a few remaining BucketCountingCrawler stuff left. For instance, in StorageStatus.render_JSON, you are still returning bucket-counter even though it returns None for it. Is this because the UI expects it? If this is the case, the UI might need to be changed as well as the backend. Another one is StorageStatus.render_count_crawler_status. Is this still needed for something if the crawler was removed?

Reassigning to markberger to fix those issues.

[daira]

remyroy: what's the output of bin/tahoe --version-and-path for you (on that branch)?

[daira]

Replying to remyroy:

I could not run the full test suite. It might be because this branch was made on a somewhat old version of tahoe-lafs. There are a bunch of "exceptions.ImportError: cannot import name HTTPConnectionPool" in the tests.

I see the problem; that branch has a requirement of ​Twisted >= 11.0.0, but HTTPConnectionPool was only made public in Twisted 12.1.0. The ​1819-cloud-merge branch has a requirement of ​Twisted >= 12.1.0 for that reason.

[remyroy]

I'm not sure if you still need the version-and-path but here it is:

allmydata-tahoe: 1.10.0.post171 [HEAD: 93b727857cc521963d1609a72ae4772c8f0bb1a0] (/home/remyroy/Projects/tahoe-lafs/src)
foolscap: 0.6.4 (/home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages/foolscap-0.6.4-py2.7.egg)
pycryptopp: 0.6.0.1206569328141510525648634803928199668821045408958 (/home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages/pycryptopp-0.6.0.1206569328141510525648634803928199668821045408958-py2.7-linux-x86_64.egg)
zfec: 1.4.7 (/home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages/zfec-1.4.7-py2.7-linux-x86_64.egg)
Twisted: 11.1.0 (/home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages/Twisted-11.1.0-py2.7-linux-x86_64.egg)
Nevow: 0.10.0 (/home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages/Nevow-0.10.0-py2.7.egg)
zope.interface: unknown (/usr/lib/python2.7/dist-packages/zope)
python: 2.7.6 (/usr/bin/python)
platform: Linux-Ubuntu_14.04-x86_64-64bit_ELF (None)
pyOpenSSL: 0.13 (/usr/lib/python2.7/dist-packages)
simplejson: 3.3.1 (/usr/lib/python2.7/dist-packages)
pycrypto: 2.6.1 (/usr/lib/python2.7/dist-packages)
pyasn1: 0.1.7 (/home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages/pyasn1-0.1.7-py2.7.egg)
mock: 1.0.1 (/home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages)
txAWS: None [(<type 'exceptions.ImportError'>, 'No module named txaws', ('/home/remyroy/Projects/tahoe-lafs/src/allmydata/__init__.py', 196, 'get_package_versions_and_locations', '__import__(modulename)'))] (None)
oauth2client: None [(<type 'exceptions.ImportError'>, 'No module named oauth2client', ('/home/remyroy/Projects/tahoe-lafs/src/allmydata/__init__.py', 196, 'get_package_versions_and_locations', '__import__(modulename)'))] (None)
python-dateutil: None [(<type 'exceptions.ImportError'>, 'No module named dateutil', ('/home/remyroy/Projects/tahoe-lafs/src/allmydata/__init__.py', 196, 'get_package_versions_and_locations', '__import__(modulename)'))] (None)
httplib2: 0.8 (/usr/lib/python2.7/dist-packages)
python-gflags: None [(<type 'exceptions.ImportError'>, 'No module named gflags', ('/home/remyroy/Projects/tahoe-lafs/src/allmydata/__init__.py', 196, 'get_package_versions_and_locations', '__import__(modulename)'))] (None)
setuptools: 0.6c16dev4 (/home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages/setuptools-0.6c16dev4.egg)

Warning: dependency 'txaws' (version None imported from None) was not found by pkg_resources.
Warning: dependency 'oauth2client' (version None imported from None) was not found by pkg_resources.
Warning: dependency 'python-dateutil' (version None imported from None) was not found by pkg_resources.
Warning: dependency 'httplib2' (version '0.8' imported from '/usr/lib/python2.7/dist-packages') was not found by pkg_resources.
Warning: dependency 'python-gflags' (version None imported from None) was not found by pkg_resources.

For debugging purposes, the PYTHONPATH was
  '/home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages'
install_requires was
  ['setuptools >= 0.6c6', 'zfec >= 1.1.0', 'simplejson >= 1.4', 'zope.interface == 3.6.0, == 3.6.1, == 3.6.2, >= 3.6.5', 'Twisted >= 11.0.0', 'foolscap >= 0.6.3', 'pyOpenSSL', 'Nevow >= 0.6.0', 'pycrypto == 2.1.0, == 2.3, >= 2.4.1', 'pyasn1 >= 0.0.8a', 'mock >= 0.8.0', 'pycryptopp >= 0.6.0']
sys.path after importing pkg_resources was
  /home/remyroy/Projects/tahoe-lafs/support/bin:
  /home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages/setuptools-0.6c16dev4.egg:
  /home/remyroy/Projects/tahoe-lafs/src:
  /home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages/pycryptopp-0.6.0.1206569328141510525648634803928199668821045408958-py2.7-linux-x86_64.egg:
  /home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages/mock-1.0.1-py2.7.egg:
  /home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages/pyasn1-0.1.7-py2.7.egg:
  /home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages/Nevow-0.10.0-py2.7.egg:
  /home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages/foolscap-0.6.4-py2.7.egg:
  /home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages/zfec-1.4.7-py2.7-linux-x86_64.egg:
  /home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages/pyutil-1.9.7-py2.7.egg:
  /home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages/zbase32-1.1.5-py2.7.egg:
  /home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages/Twisted-11.1.0-py2.7-linux-x86_64.egg:
  /home/remyroy/Projects/tahoe-lafs/support/lib/python2.7/site-packages:
  /usr/lib/python2.7:
  /usr/lib/python2.7/plat-x86_64-linux-gnu:
  /usr/lib/python2.7/lib-tk:
  /usr/lib/python2.7/lib-old:
  /usr/lib/python2.7/lib-dynload:
  /usr/local/lib/python2.7/dist-packages:
  /usr/lib/python2.7/dist-packages:
  /usr/lib/python2.7/dist-packages/PILcompat:
  /usr/lib/python2.7/dist-packages/gtk-2.0:
  /usr/lib/python2.7/dist-packages/ubuntu-sso-client

I was using Twisted 11.1.

[daira]

Thanks, that confirms that it was the Twisted version.

I've rebased markberger's branch on top of 1819-cloud-merge: ​https://github.com/tahoe-lafs/tahoe-lafs/commits/1836-use-leasedb-for-share-count

[remyroy]

Just ran the test suite on ​https://github.com/tahoe-lafs/tahoe-lafs/commits/1836-use-leasedb-for-share-count and everything seems fine.

[daira]

SELECT COUNT(*), SUM(`used_space`)
  FROM (SELECT `used_space`
          FROM `shares` s JOIN `leases` l"
          ON (s.`storage_index` = l.`storage_index` AND s.`shnum` = l.`shnum`)
          GROUP BY s.`storage_index`, s.`shnum`)

My relational algebra may be a little rusty, but can't that be simplified to:

SELECT COUNT(*), SUM(`used_space`)
  FROM `shares` s JOIN `leases` l"
  ON (s.`storage_index` = l.`storage_index` AND s.`shnum` = l.`shnum`)
  GROUP BY s.`storage_index`, s.`shnum`

?

[daira]

Also see comments ​https://github.com/tahoe-lafs/tahoe-lafs/commit/50a617f7c629d316e0e5a9f63576f119ac9f8749#commitcomment-6216938 and ​https://github.com/tahoe-lafs/tahoe-lafs/commit/b9f1d00fadd8e859a06d5641a4acb491b50d4868#commitcomment-6216968.

[daira]

Oh, I was responsible for the variation with the double SELECT ... FROM ... in comment:9 . I wonder whether there was any reason for writing it that way?

[zooko]

Related discussion: ​https://github.com/tahoe-lafs/tahoe-lafs/commit/006a04976eb42f56c118c34adf2ddb54c1605edb#commitcomment-6229240

[warner]

Milestone renamed

[warner]

renaming milestone

[exarkun]

Moving open issues out of closed milestones.

[exarkun]

The established line of development on the "cloud backend" branch has been abandoned. This ticket is being closed as part of a batch-ticket cleanup for "cloud backend"-related tickets.

If this is a bug, it is probably genuinely no longer relevant. The "cloud backend" branch is too large and unwieldy to ever be merged into the main line of development (particularly now that the Python 3 porting effort is significantly underway).

If this is a feature, it may be relevant to some future efforts - if they are sufficiently similar to the "cloud backend" effort - but I am still closing it because there are no immediate plans for a new development effort in such a direction.

Tickets related to the "leasedb" are included in this set because the "leasedb" code is in the "cloud backend" branch and fairly well intertwined with the "cloud backend". If there is interest in lease implementation change at some future time then that effort will essentially have to be restarted as well.