#1833 new enhancement

storage server deletes garbage shares itself instead of waiting for crawler to notice them

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.

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

Change History (5)

comment:1 Changed at 2012-10-30T22:40:05Z by zooko

  • Description modified (diff)

comment:2 Changed at 2012-10-30T22:45:24Z by zooko

  • Description modified (diff)

comment:3 Changed at 2012-11-19T19:17:08Z by davidsarah

Relevant to #1862 (removing shares more quickly than one day).

comment:4 Changed at 2013-05-27T20:27:59Z by zooko

  • Description modified (diff)

This would fix #1987.

comment:5 Changed at 2013-11-14T18:23:27Z by zooko

This might fix #1921.

Note: See TracTickets for help on using tickets.