[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