Opened at 2012-10-30T22:39:10Z
Last modified at 2013-11-14T18:23:27Z
#1833 new enhancement
storage server deletes garbage shares itself instead of waiting for crawler to notice them — at Version 1
Reported by: | zooko | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | undecided |
Component: | code-storage | Version: | 1.9.2 |
Keywords: | leases garbage-collection accounting | Cc: | |
Launchpad Bug: |
Description (last modified by zooko)
Currently, the "lease crawler" or "accounting crawler" is responsible for deleting shares that have lost all their leases (by cancellation or expiry).
I propose that this be done instead by the storage server maintaining a persistent set of shares to be deleted. When lease-updating step (which, in #666, is synchronous and fast) has identified a share that has no more leases, the share's id gets added to the persistent set of shares to delete. A long-running, persistent, duty-cycle-limited processes deletes those shares from the backend and removes their ids from the set of shares-to-delete. This is cleaner and more efficient than using a crawler, which has to visit all shares and which never stops twitching, since this has to visit only shares that have been marked as to-delete, and it quiesces when there is nothing to delete.