#1004 new defect

how to fix 'multiple versions are recoverable'?

Reported by: humberto Owned by: nobody
Priority: major Milestone: 1.15.0
Component: code-mutable Version: 1.6.1
Keywords: mutable recovery repair Cc:
Launchpad Bug:

Description (last modified by daira)

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.

Change History (13)

comment:1 Changed at 2010-03-24T17:42:38Z by humberto

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

comment:2 Changed at 2010-03-25T00:01:35Z by davidsarah

  • Component changed from unknown to code-mutable

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

comment:3 Changed at 2010-05-27T22:12:21Z by zooko

  • Milestone changed from undecided to 1.8.0

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. :-)

comment:4 Changed at 2010-08-12T21:42:25Z by zooko

  • Milestone changed from 1.8.0 to soon

comment:5 Changed at 2012-03-29T20:59:08Z by davidsarah

  • Milestone changed from soon to 1.10.0

comment:6 follow-up: Changed at 2013-11-15T23:36:51Z by daira

  • Description modified (diff)
  • Milestone changed from soon to 1.12.0

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.

comment:7 in reply to: ↑ 6 Changed at 2013-11-16T04:13:42Z by zooko

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!

comment:8 follow-up: Changed at 2013-11-19T03:27:49Z by PRabahy

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 --- <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.

Last edited at 2013-11-19T03:28:28Z by PRabahy (previous) (diff)

comment:9 Changed at 2013-11-19T18:40:35Z by zooko

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
Last edited at 2013-11-19T19:07:37Z by zooko (previous) (diff)

comment:10 in reply to: ↑ 8 Changed at 2013-11-19T19:35:13Z by daira

Replying to PRabahy:

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

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

comment:11 Changed at 2016-03-22T05:02:25Z by warner

  • Milestone changed from 1.12.0 to 1.13.0

Milestone renamed

comment:12 Changed at 2016-06-28T18:17:14Z by warner

  • Milestone changed from 1.13.0 to 1.14.0

renaming milestone

comment:13 Changed at 2020-06-30T14:45:13Z by exarkun

  • Milestone changed from 1.14.0 to 1.15.0

Moving open issues out of closed milestones.

Note: See TracTickets for help on using tickets.