[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