how to fix 'multiple versions are recoverable'? #1004

New Issue

tahoe-lafs · 2010-03-24T17:41:12Z

humberto commented

2010-03-24 17:41:12 +00:00

I have a couple of directories that are

Not Healthy! : Unhealthy: multiple versions are recoverable

 * Report:

   Recoverable Versions: 6*seq24-wgxp/10*seq26-4tdb
   Unhealthy: there are multiple recoverable versions
   Best Recoverable Version: seq26-4tdb

I can't see how to fix this. A deep check with the repair checkbox
leaves the directories in the same state.

A simple check with the repair checkbox shows me the versions available, but I didn't see how to fix the directory.

I have a couple of directories that are > Not Healthy! : Unhealthy: multiple versions are recoverable * Report: Recoverable Versions: 6*seq24-wgxp/10*seq26-4tdb Unhealthy: there are multiple recoverable versions Best Recoverable Version: seq26-4tdb I can't see how to fix this. A deep check with the repair checkbox leaves the directories in the same state. A simple check with the repair checkbox shows me the versions available, but I didn't see how to fix the directory.

tahoe-lafs added the

labels 2010-03-24 17:41:12 +00:00

tahoe-lafs added this to the undecided milestone 2010-03-24 17:41:12 +00:00

humberto commented

2010-03-24 17:42:38 +00:00

Zooko sent a list of related tickets:

Here are all the tickets that look vaguely related to the topic of
"robust upload/download of mutables":

http://allmydata.org/trac/tahoe-lafs/ticket/232# Peer selection
doesn't rebalance shares on overwrite of mutable file.
http://allmydata.org/trac/tahoe-lafs/ticket/474# uncaught exception in
mutable-retrieve: UCW between mapupdate and retrieve
http://allmydata.org/trac/tahoe-lafs/ticket/540# inappropriate
"uncoordinated write error" after handling a server failure
http://allmydata.org/trac/tahoe-lafs/ticket/541# foolscap
'reference'-token bug workaround in mutable publish
http://allmydata.org/trac/tahoe-lafs/ticket/546# mutable-file surprise
shares raise inappropriate UCWE
http://allmydata.org/trac/tahoe-lafs/ticket/547# mapupdate(MODE_WRITE)
triggers on a false boundary
http://allmydata.org/trac/tahoe-lafs/ticket/548# mutable publish sends
queries to servers that have already been asked
http://allmydata.org/trac/tahoe-lafs/ticket/549# MODE_WRITE mapupdate:
maybe increase epsilon to handle large batches of new servers better
http://allmydata.org/trac/tahoe-lafs/ticket/846#
allmydata.test.test_system.SystemTest.test_mutable sometimes hangs on
a slow machine
http://allmydata.org/trac/tahoe-lafs/ticket/893# UCWE when mapupdate
gives up too early, then server errors require replacement servers

Zooko sent a list of related tickets: Here are all the tickets that look vaguely related to the topic of "robust upload/download of mutables": <http://allmydata.org/trac/tahoe-lafs/ticket/232># Peer selection doesn't rebalance shares on overwrite of mutable file. <http://allmydata.org/trac/tahoe-lafs/ticket/474># uncaught exception in mutable-retrieve: UCW between mapupdate and retrieve <http://allmydata.org/trac/tahoe-lafs/ticket/540># inappropriate "uncoordinated write error" after handling a server failure <http://allmydata.org/trac/tahoe-lafs/ticket/541># foolscap 'reference'-token bug workaround in mutable publish <http://allmydata.org/trac/tahoe-lafs/ticket/546># mutable-file surprise shares raise inappropriate UCWE <http://allmydata.org/trac/tahoe-lafs/ticket/547># mapupdate(MODE_WRITE) triggers on a false boundary <http://allmydata.org/trac/tahoe-lafs/ticket/548># mutable publish sends queries to servers that have already been asked <http://allmydata.org/trac/tahoe-lafs/ticket/549># MODE_WRITE mapupdate: maybe increase epsilon to handle large batches of new servers better <http://allmydata.org/trac/tahoe-lafs/ticket/846># allmydata.test.test_system.SystemTest.test_mutable sometimes hangs on a slow machine <http://allmydata.org/trac/tahoe-lafs/ticket/893># UCWE when mapupdate gives up too early, then server errors require replacement servers

davidsarah commented

2010-03-25 00:01:35 +00:00

Reformatting the list in Humberto's comment:

#232 Peer selection doesn't rebalance shares on overwrite of mutable file
#474 uncaught exception in mutable-retrieve: UCW between mapupdate and retrieve
#540 inappropriate "uncoordinated write error" after handling a server failure
#541 foolscap 'reference'-token bug workaround in mutable publish
#546 mutable-file surprise shares raise inappropriate UCWE
#547 mapupdate(MODE_WRITE) triggers on a false boundary
#548 mutable publish sends queries to servers that have already been asked
#549 MODE_WRITE mapupdate: maybe increase epsilon to handle large batches of new servers better
#846 allmydata.test.test_system.SystemTest.test_mutable sometimes hangs on a slow machine
#893 UCWE when mapupdate gives up too early, then server errors require replacement servers

Reformatting the list in Humberto's comment: * #232 Peer selection doesn't rebalance shares on overwrite of mutable file * #474 uncaught exception in mutable-retrieve: UCW between mapupdate and retrieve * #540 inappropriate "uncoordinated write error" after handling a server failure * #541 foolscap 'reference'-token bug workaround in mutable publish * #546 mutable-file surprise shares raise inappropriate UCWE * #547 mapupdate(MODE_WRITE) triggers on a false boundary * #548 mutable publish sends queries to servers that have already been asked * #549 MODE_WRITE mapupdate: maybe increase epsilon to handle large batches of new servers better * #846 allmydata.test.test_system.SystemTest.test_mutable sometimes hangs on a slow machine * #893 UCWE when mapupdate gives up too early, then server errors require replacement servers

tahoe-lafs added

code-mutable

and removed

unknown

labels 2010-03-25 00:01:35 +00:00

zooko commented

2010-05-27 22:12:21 +00:00

It's really bothering me that mutable file upload and download behavior is so finicky, buggy, inefficient, hard to understand, different from immutable file upload and download behavior, etc. So I'm putting a bunch of tickets into the "1.8" Milestone. I am not, however, at this time, volunteering to work on these tickets, so it might be a mistake to put them into the 1.8 Milestone, but I really hope that someone else will volunteer or that I will decide to do it myself. :-)

zooko modified the milestone from undecided to 1.8.0

2010-05-27 22:12:21 +00:00

zooko modified the milestone from 1.8.0 to soon

2010-08-12 21:42:25 +00:00

tahoe-lafs modified the milestone from soon to 1.10.0

2012-03-29 20:59:08 +00:00

daira commented

2013-11-15 23:36:51 +00:00

Proposed behaviour: mutable repair should delete (by setting the container to zero length) shares of previous versions, after confirming that the current version meets the happiness threshold. See also #614, #1057 and #2060.

tahoe-lafs modified the milestone from soon to 1.12.0

2013-11-15 23:36:51 +00:00

zooko commented

2013-11-16 04:13:42 +00:00

Replying to daira:

Proposed behaviour: mutable repair should delete (by setting the container to zero length) shares of previous versions, after confirming that the current version meets the happiness threshold.

Sounds good to me!

Replying to [daira](/tahoe-lafs/trac-2024-07-25/issues/1004#issuecomment-76594): > Proposed behaviour: mutable repair should delete (by setting the container to zero length) shares of previous versions, after confirming that the current version meets the happiness threshold. Sounds good to me!

PRabahy commented

2013-11-19 03:27:49 +00:00

I hit this under slightly different circumstances.

C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\bin>tahoe deep-check --repair CryptoResearch: ERROR: MustForceRepairError(There were unrecoverable newer versions, so force=Tr ue must be passed to the repair() operation) "[Failure instance: Traceback: <class 'allmydata.mutable.repairer.MustForceRepai rError'>: There were unrecoverable newer versions, so force=True must be passed to the repair() operation" C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twis ted-11.0.0-py2.7-win32.egg\twisted\internet\base.py:793:runUntilCurrent C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\fool scap-0.6.4-py2.7.egg\foolscap\eventual.py:26:_turn C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twis ted-11.0.0-py2.7-win32.egg\twisted\internet\defer.py:361:callback C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twis ted-11.0.0-py2.7-win32.egg\twisted\internet\defer.py:455:_startRunCallbacks --- --- C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twis ted-11.0.0-py2.7-win32.egg\twisted\internet\defer.py:542:_runCallbacks c:\users\prabahy\downloads\allmydata-tahoe-1.10.0\src\allmydata\mutable\repairer .py:83:_got_full_servermap

Edit: Ouch, sorry about the formatting, but all the details are there.

I hit this under slightly different circumstances. C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\bin>tahoe deep-check --repair [CryptoResearch](wiki/CryptoResearch): ERROR: [MustForceRepairError](wiki/MustForceRepairError)(There were unrecoverable newer versions, so force=Tr ue must be passed to the repair() operation) "[Failure instance: Traceback: <class 'allmydata.mutable.repairer.MustForceRepai rError'>: There were unrecoverable newer versions, so force=True must be passed to the repair() operation" C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twis ted-11.0.0-py2.7-win32.egg\twisted\internet\base.py:793:runUntilCurrent C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\fool scap-0.6.4-py2.7.egg\foolscap\eventual.py:26:_turn C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twis ted-11.0.0-py2.7-win32.egg\twisted\internet\defer.py:361:callback C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twis ted-11.0.0-py2.7-win32.egg\twisted\internet\defer.py:455:_startRunCallbacks --- <exception caught here> --- C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twis ted-11.0.0-py2.7-win32.egg\twisted\internet\defer.py:542:_runCallbacks c:\users\prabahy\downloads\allmydata-tahoe-1.10.0\src\allmydata\mutable\repairer .py:83:_got_full_servermap Edit: Ouch, sorry about the formatting, but all the details are there.

zooko commented

2013-11-19 18:40:35 +00:00

Thanks for the bug report, PRabahy! Here's an attempt to untangle the formatting:

C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\bin>tahoe deep-check --repair CryptoResearch:
ERROR: MustForceRepairError(There were unrecoverable newer versions, so force=True must be passed to the repair() operation)
"[Failure instance: Traceback: <class 'allmydata.mutable.repairer.MustForceRepairError'>: There were unrecoverable newer versions, so force=True must be passed to the repair() operation"
C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twisted-11.0.0-py2.7-win32.egg\twisted\internet\base.py:793:runUntilCurrent
C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\foolscap-0.6.4-py2.7.egg\foolscap\eventual.py:26:_turn
C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twisted-11.0.0-py2.7-win32.egg\twisted\internet\defer.py:361:callback
C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twisted-11.0.0-py2.7-win32.egg\twisted\internet\defer.py:455:_startRunCallbacks
--- <exception caught here> ---
C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twisted-11.0.0-py2.7-win32.egg\twisted\internet\defer.py:542:_runCallbacks
c:\users\prabahy\downloads\allmydata-tahoe-1.10.0\src\allmydata\mutable\repairer.py:83:_got_full_servermap

Thanks for the bug report, PRabahy! Here's an attempt to untangle the formatting: ``` C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\bin>tahoe deep-check --repair CryptoResearch: ERROR: MustForceRepairError(There were unrecoverable newer versions, so force=True must be passed to the repair() operation) "[Failure instance: Traceback: <class 'allmydata.mutable.repairer.MustForceRepairError'>: There were unrecoverable newer versions, so force=True must be passed to the repair() operation" C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twisted-11.0.0-py2.7-win32.egg\twisted\internet\base.py:793:runUntilCurrent C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\foolscap-0.6.4-py2.7.egg\foolscap\eventual.py:26:_turn C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twisted-11.0.0-py2.7-win32.egg\twisted\internet\defer.py:361:callback C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twisted-11.0.0-py2.7-win32.egg\twisted\internet\defer.py:455:_startRunCallbacks --- <exception caught here> --- C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twisted-11.0.0-py2.7-win32.egg\twisted\internet\defer.py:542:_runCallbacks c:\users\prabahy\downloads\allmydata-tahoe-1.10.0\src\allmydata\mutable\repairer.py:83:_got_full_servermap ```

daira commented

2013-11-19 19:35:13 +00:00

Replying to PRabahy:

I hit this under slightly different circumstances. [...]

I think that is probably a different bug -- filed as #2109.

Replying to [PRabahy](/tahoe-lafs/trac-2024-07-25/issues/1004#issuecomment-76597): > I hit this under slightly different circumstances. [...] I think that is probably a different bug -- filed as #2109.

warner commented

2016-03-22 05:02:25 +00:00

Milestone renamed

warner modified the milestone from 1.12.0 to 1.13.0

2016-03-22 05:02:25 +00:00

warner commented

2016-06-28 18:17:14 +00:00

renaming milestone

warner modified the milestone from 1.13.0 to 1.14.0

2016-06-28 18:17:14 +00:00

exarkun commented

2020-06-30 14:45:13 +00:00