[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
Tue Jun 18 00:49:19 UTC 2013


#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:           |
-------------------------+-------------------------------------------------

Old description:

> Particularly with my root directory, I often find that 9 shares of seqN
> are available compared to 10 desired. I do a repair, and this results in
> 10 shares of seqN+1 and then 9 are deleted. Then the next day there are 9
> of seqN+1 and 1 of seqN, and the file is again not healthy. This repeats
> daily.
>
> It seems that the missing seqN shares should be generated and placed, and
> then when servers churn more it's likely that 10 can still be found, and
> no unrecoverable versions. Perhaps I don't get something, but the current
> behavior is not stable with intermittent servers.
>
> I have observed this problem with directories, but it seems likely that
> it applies to all ~~im~~mutable files.

New description:

 Particularly with my root directory, I often find that 9 shares of seqN
 are available compared to 10 desired. I do a repair, and this results in
 10 shares of seqN+1 and then 9 are deleted. Then the next day there are 9
 of seqN+1 and 1 of seqN, and the file is again not healthy. This repeats
 daily.

 It seems that the missing seqN shares should be generated and placed, and
 then when servers churn more it's likely that 10 can still be found, and
 no unrecoverable versions. Perhaps I don't get something, but the current
 behavior is not stable with intermittent servers.

 I have observed this problem with directories, but it seems likely that it
 applies to all ~~im~~mutable files.

--

Comment (by daira):

 Incidentally, the comment:19 algorithm never makes things worse even in
 the case of partition, because it only deletes shares of a lower version
 than a version that is stored happily, even when run on an arbitrary
 partition of a grid.

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


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