[tahoe-lafs-trac-stream] [tahoe-lafs] #1833: storage server deletes garbage shares itself instead of waiting for crawler to notice them

[tahoe-lafs]

#1833: storage server deletes garbage shares itself instead of waiting for crawler
to notice them
-------------------------------------------------+-------------------------
 Reporter:  zooko                                |          Owner:
     Type:  enhancement                          |         Status:  new
 Priority:  normal                               |      Milestone:
Component:  code-storage                         |  undecided
 Keywords:  leases garbage-collection            |        Version:  1.9.2
  accounting                                     |  Launchpad Bug:
-------------------------------------------------+-------------------------
 Currently, the "lease crawler" or "accounting crawler" is respnsible 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.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1833>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage