Failure: allmydata.mutable.common.UncoordinatedWriteError #1583

New Issue

tahoe-lafs · 2011-11-14T21:43:21Z

killyourtv commented

2011-11-14 21:43:21 +00:00

I have patched my installation of tahoe 1.9.0 with the patch from ticket #1010 (which worked perfectly with v1.8.3) for use on the I2P network.

Trying to repair my share I get the following error:

$ tahoe check --repair tahoe:
ERROR: 500 Internal Server Error
"Traceback (most recent call last):\x0aFailure: allmydata.mutable.common.UncoordinatedWriteError: \x0a"

This error will show no matter how many times the command is re-run. (I tried re-running it 10 times and the error came up each time).

After reverting back to v1.8.3:

$ tahoe check --repair tahoe:
Summary: not healthy
 storage index: ft4svdmjfm5th3sunuh6hhfcma
 good-shares: 4 (encoding is 3-of-10)
 wrong-shares: 5
 repair successful

Running the command again:

$ tahoe check --repair tahoe:
Summary: healthy
 storage index: ft4svdmjfm5th3sunuh6hhfcma
 good-shares: 10 (encoding is 3-of-10)
 wrong-shares: 0

A deep-check is currently running on the share using v1.8.3.

The used packages:


foolscap: 0.6.2,
pycryptopp: 0.5.29,
zfec: 1.4.22,
Twisted: 11.0.0,
Nevow: 0.10.0,
zope.interface: unknown,
python: 2.7.2+,
platform: Linux-debian_wheezy/sid-x86_64-64bit_ELF,
pyOpenSSL: 0.13,
simplejson: 2.2.0,
pycrypto: 2.4,
pyasn1: unknown,
mock: 0.7.2,
sqlite3: 2.6.0 [sqlite 3.7.9],
setuptools: 0.6 [distribute]

Please let me know if any other info would be of use.

I have patched my installation of tahoe 1.9.0 with the patch from ticket #1010 (which worked perfectly with v1.8.3) for use on the I2P network. Trying to repair my share I get the following error: ``` $ tahoe check --repair tahoe: ERROR: 500 Internal Server Error "Traceback (most recent call last):\x0aFailure: allmydata.mutable.common.UncoordinatedWriteError: \x0a" ``` This error will show no matter how many times the command is re-run. (I tried re-running it 10 times and the error came up each time). After reverting back to v1.8.3: ``` $ tahoe check --repair tahoe: Summary: not healthy storage index: ft4svdmjfm5th3sunuh6hhfcma good-shares: 4 (encoding is 3-of-10) wrong-shares: 5 repair successful ``` Running the command again: ``` $ tahoe check --repair tahoe: Summary: healthy storage index: ft4svdmjfm5th3sunuh6hhfcma good-shares: 10 (encoding is 3-of-10) wrong-shares: 0 ``` A deep-check is currently running on the share using v1.8.3. The used packages: ``` foolscap: 0.6.2, pycryptopp: 0.5.29, zfec: 1.4.22, Twisted: 11.0.0, Nevow: 0.10.0, zope.interface: unknown, python: 2.7.2+, platform: Linux-debian_wheezy/sid-x86_64-64bit_ELF, pyOpenSSL: 0.13, simplejson: 2.2.0, pycrypto: 2.4, pyasn1: unknown, mock: 0.7.2, sqlite3: 2.6.0 [sqlite 3.7.9], setuptools: 0.6 [distribute] ``` Please let me know if any other info would be of use.

tahoe-lafs added the

labels 2011-11-14 21:43:21 +00:00

tahoe-lafs added this to the undecided milestone 2011-11-14 21:43:21 +00:00

killyourtv commented

2011-11-16 00:17:30 +00:00

...and for what it's worth, the deep-check on this share ultimately failed but at least some of it could be repaired.

killyourtv commented

2011-11-18 00:07:32 +00:00

Correction: Of course I mean the patches in #1007 and #1010 (not just #1010 like I initially wrote)

zooko commented

2011-11-19 02:51:42 +00:00

Hi killyourtv, I just saw this ticket for the first time. This sounds like a serious regression! Thank you for the bug report. Adding Cc: kevan in case he also hasn't noticed this ticket yet.

Could you look for incidents report files in the ~/.tahoe/logs/incidents directory next time this happens? (I.e. after reproducing it)

Also, you could push the "Report an Incident" button on the welcome page immediately after triggering the problem? That will produce another incident report file.

Hi killyourtv, I just saw this ticket for the first time. This sounds like a serious regression! Thank you for the bug report. Adding Cc: kevan in case he also hasn't noticed this ticket yet. Could you look for incidents report files in the `~/.tahoe/logs/incidents` directory next time this happens? (I.e. after reproducing it) Also, you could push the "Report an Incident" button on the welcome page immediately after triggering the problem? That will produce another incident report file.

zooko added

critical

and removed

major

labels 2011-11-19 02:51:57 +00:00

zooko commented

2011-11-19 02:53:29 +00:00

Hm... this issue sounds familiar. Searching for tickets tagged ucwe I find #893 and #540. Your issue probably can't be exactly either of these, because it doesn't happen with v1.8.3. Still, it might be related to one of those, so a debugger might want to study them.

Hm... this issue sounds familiar. Searching for tickets tagged `ucwe` I find #893 and #540. Your issue probably can't be exactly either of these, because it doesn't happen with v1.8.3. Still, it might be related to one of those, so a debugger might want to study them.

zooko added

1.9.0

and removed

1.9.0b1

labels 2011-11-19 02:58:54 +00:00

killyourtv commented

2011-11-19 15:49:28 +00:00

Attachment incident-2011-11-19--00-37-24Z-5dwoh6q.flog.bz2 (21163 bytes) added

Incident report immediately after receiving an UncoordinatedWriteError during a repair operation

**Attachment** incident-2011-11-19--00-37-24Z-5dwoh6q.flog.bz2 (21163 bytes) added Incident report immediately after receiving an [UncoordinatedWriteError](wiki/UncoordinatedWriteError) during a repair operation

incident-2011-11-19--00-37-24Z-5dwoh6q.flog.bz2

21 KiB

killyourtv commented

2011-11-19 15:58:08 +00:00

The attached file incident-2011-11-19--00-37-24Z-5dwoh6q.flog.bz2 was from yesterday, created via the "Report a Problem" button (and stashed into another directory) within (IIRC) a few seconds of the failure.

The attached file *incident-2011-11-19--00-37-24Z-5dwoh6q.flog.bz2* was from yesterday, created via the "Report a Problem" button (and stashed into another directory) within (IIRC) a few seconds of the failure.

killyourtv commented

2011-12-01 10:40:31 +00:00

Seems to have been fixed by the patch in #1628

tahoe-lafs added the

duplicate

label 2011-12-13 22:56:05 +00:00

killyourtv closed this issue

2011-12-13 22:56:05 +00:00

Sign in to join this conversation.