Allow deep-check to continue after error #1955

Closed
opened 2013-04-25 18:20:56 +00:00 by killyourtv · 1 comment
killyourtv commented 2013-04-25 18:20:56 +00:00
Owner

It would be useful to have tahoe deep-check --repair continue, even if one file cannot be repaired due to encountering a "not enough shares" error.

Such as

'debian/pool/main/b/bitcoin': not healthy
 repair successful
'debian/pool/main/b/bitcoin/bitcoin-qt_0.5.2-1_amd64.deb': not healthy
 repair successful
'debian/pool/main/b/bitcoin/bitcoin-qt_0.5.2-1_i386.deb': not healthy
 repair successful
'debian/pool/main/b/bitcoin/bitcoin-qt_0.5.2-1squeeze1_amd64.deb': not healthy
 repair successful
ERROR: NotEnoughSharesError(ran out of shares: complete=sh5 pending=Share(sh9-on-5ithai) overdue= unused= need 5. Last failure: None)
"[Failure instance: Traceback (failure with no frames): <class 'allmydata.interfaces.NotEnoughSharesError'>: ran out of shares: complete=sh5 pending=Share(sh9-on-5ithai) overdue= unused= need 5. Last failure: None"

At this point the deep-check aborts, even though the subsequent files can be successfully repaired.

To work around this I created a shoddy script that runs "tahoe deep-check -v --add-lease", saves the output to a file, then runs an individual repair on each file/directory that was reported as 'Unhealthy|Not Healthy'. My workaround may be kinda daft but until I remove the irreparable file(s)/director(y|ies), deep-checking won't complete.


Note: IIRC directories are Unhealthy and files are Not Healthy when deep-check is run without --repair. If run with --repair, not healthy is in lower case as shown above. I don't know if the inconsistency (i.e. case or not healthy VS unhealthy) is a bug (which is why I didn't file one for this), but I didn't expect it.

It would be useful to have `tahoe deep-check --repair` continue, even if one file cannot be repaired due to encountering a "not enough shares" error. Such as ``` 'debian/pool/main/b/bitcoin': not healthy repair successful 'debian/pool/main/b/bitcoin/bitcoin-qt_0.5.2-1_amd64.deb': not healthy repair successful 'debian/pool/main/b/bitcoin/bitcoin-qt_0.5.2-1_i386.deb': not healthy repair successful 'debian/pool/main/b/bitcoin/bitcoin-qt_0.5.2-1squeeze1_amd64.deb': not healthy repair successful ERROR: NotEnoughSharesError(ran out of shares: complete=sh5 pending=Share(sh9-on-5ithai) overdue= unused= need 5. Last failure: None) "[Failure instance: Traceback (failure with no frames): <class 'allmydata.interfaces.NotEnoughSharesError'>: ran out of shares: complete=sh5 pending=Share(sh9-on-5ithai) overdue= unused= need 5. Last failure: None" ``` At this point the deep-check aborts, even though the subsequent files can be successfully repaired. To work around this I created a shoddy script that runs "tahoe deep-check -v --add-lease", saves the output to a file, then runs an individual repair on each file/directory that was reported as 'Unhealthy|Not Healthy'. My workaround may be kinda daft but until I remove the irreparable file(s)/director(y|ies), deep-checking won't complete. ---- Note: IIRC directories are **Unhealthy** and files are **Not Healthy** when deep-check is run without --repair. If run with --repair, **not healthy** is in lower case as shown above. I don't know if the inconsistency (i.e. *case* or *not healthy* VS *unhealthy*) is a bug (which is why I didn't file one for this), but I didn't expect it.
tahoe-lafs added the
unknown
normal
enhancement
1.9.2
labels 2013-04-25 18:20:56 +00:00
tahoe-lafs added this to the undecided milestone 2013-04-25 18:20:56 +00:00
daira commented 2013-04-26 02:00:16 +00:00
Author
Owner

Duplicate of #755.

The difference in case is not intentional.

Duplicate of #755. The difference in case is not intentional.
tahoe-lafs added the
duplicate
label 2013-04-26 02:00:16 +00:00
daira closed this issue 2013-04-26 02:00:16 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: tahoe-lafs/trac-2024-07-25#1955
No description provided.