[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