[tahoe-lafs-trac-stream] [Tahoe-LAFS] #1835: stop grovelling the whole storage backend looking for externally-added shares to add a lease to

Tahoe-LAFS trac at tahoe-lafs.org
Wed Oct 19 01:15:02 UTC 2016


#1835: stop grovelling the whole storage backend looking for externally-added
shares to add a lease to
-------------------------+-------------------------------------------------
     Reporter:  zooko    |      Owner:
         Type:           |     Status:  new
  enhancement            |
     Priority:  normal   |  Milestone:  undecided
    Component:  code-    |    Version:  1.9.2
  storage                |   Keywords:  leases garbage-collection
   Resolution:           |  accounting
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by warner):

 I'd be ok with either requiring a specific 'add a foreign share' command,
 or maybe a magic directory that you drop the share files into, instead of
 expecting spontaneous discovery of new shares in their final location. I
 think I want it to be reasonably efficient for moving a large number of
 shares at once (so I suspect that pushing them in over HTTP wouldn't
 count).

 I must admit that I've never actually used this feature in practice. I've
 had development cycles where I'd upload a file, then corrupt or delete or
 move shares around manually, then re-upload or repair to see what
 happened. I could imagine adding a new `tahoe debug` command to delete a
 share, or add one, that I could use for this sort of development work
 instead of relying on automatic discovery of sharefiles.

 I originally wanted it so that sysadmins could feel comfortable treating
 shares as plain files (without associated magic), so they could e.g.
 migrate a server to a new machine with 'scp', or merge two servers, or
 merge a plain backup of the shares/ directory with shares that were added
 later, or something. Having real databases is a super-useful performance
 improvement, but it does give up on this "cp-based sysadmin" technique a
 bit. But I don't think I could argue that it's particularly important to
 keep it around.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1835#comment:7>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage


More information about the tahoe-lafs-trac-stream mailing list