[tahoe-lafs-trac-stream] [tahoe-lafs] #1209: repair of mutable files/directories should not increment the sequence number

[tahoe-lafs]

#1209: repair of mutable files/directories should not increment the sequence
number
-------------------------+-------------------------------------------------
     Reporter:  gdt      |      Owner:  davidsarah
         Type:  defect   |     Status:  assigned
     Priority:  major    |  Milestone:  1.11.0
    Component:  code-    |    Version:  1.8.0
  mutable                |   Keywords:  repair mutable preservation space-
   Resolution:           |  efficiency
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by davidsarah):

 Replying to [comment:18 gdt]:
 > I think davidsarah's proposed algorithm is a good choice.  A few
 comments:
 >   * if there are shares of a version Q < R, then S = R, not Q.  This
 follows from the algorithm, but in a design doc perhaps should be made
 more obvious: stray shares of a version less than the highest recoverable
 version are not a problem.
 >   * In the case where R is repaired, stray shares of a lower version
 should be removed.
 >   * in the case where S+1 is uploaded, shares of R, and actually shares
 of <=S should be removed.

 I agree. To make this more explicit:

 1. Find the highest recoverable sequence number, R. If there is no
 recoverable sequence number, abort.
 2. Find the highest sequence number for which there exist any shares, S.
 3. If R == S,
     * Repair version R using the algorithm in ticket:1130#comment:12 . Set
 Recovered := R.
    Otherwise,
     * Download version R and upload it to version S+1. Set Recovered :=
 S+1.
 4. If the client's happiness threshold is met for shares of sequence
 number Recovered, remove all known shares with sequence numbers <
 Recovered.

 (The reason to only do the removal when the Recovered version is happy, is
 in case of a partition where different clients can see different subsets
 of servers. In that case, removing shares is a bad idea unless we know
 that the Recovered version has been stored reliably, not just recoverably.
 Also, we shouldn't remove shares from servers that weren't considered in
 steps 1 and 2, if they have connected in the meantime.)

 >   * if R is recoverable and there are shares of S > R, then it's really
 not clear what should happen.  One possibility is to wait for a while
 (days?), keeping checking, and hoping there are enough S.  But this is
 probably a very unlikely, and it's unclear what ought to happen, so I
 would defer that nuance to later.

 The algorithm says to upload to version S+1 in that case. I think this is
 the right thing.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1209#comment:19>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage