[tahoe-lafs-trac-stream] [tahoe-lafs] #1209: repair of mutable files/directories should not increment the sequence number
tahoe-lafs
trac at tahoe-lafs.org
Thu Mar 29 20:20:43 UTC 2012
#1209: repair of mutable files/directories should not increment the sequence
number
-------------------------+-------------------------------------------------
Reporter: gdt | Owner: davidsarah
Type: defect | Status: assigned
Priority: major | Milestone: soon
Component: code- | Version: 1.8.0
mutable | Keywords: repair mutable preservation space-
Resolution: | efficiency
Launchpad Bug: |
-------------------------+-------------------------------------------------
Comment (by davidsarah):
Brian wrote on tahoe-dev:
> I haven't looked at that code for a long time, but it occurs to me that
what it wants is a checker-results flag that says whether the unhealthy
status is due to the presence of multiple versions or not. In terms of the
{{{ServerMap}}} object, I think that's just:
> {{{len(sm.recoverable_versions()) + len(sm.unrecoverable_versions()) >
1}}}
> We only need to do the full download+upload cycle (which increments the
version number) if there are multiple versions present. If we're just
missing a couple of shares (or some are corrupted and could be replaced),
then the number of versions ==1 and we should do a non-incrementing form
of repair.
> I think we'll need new Repairer code to do that, though. Something to
set the new version equal to the existing version, to avoid sending
updates to existing correct shares, and something to make sure the
generated test-vectors are ok with all that. Not trivial, but not a huge
task either.
--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1209#comment:12>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage
More information about the tahoe-lafs-trac-stream
mailing list