webapi PUT via multiple nodes can cause directory corruption but does not report UncoordinatedWriteError

[stott]

Multiple simultaneous Tahoe put(s) via web API cause directory level corruption resulting in no recoverable data.

To recreate

Step 1.) Create Directory ; Get directory writecap.

Step 2.) Using 61 .JPG files avg 1.7MB use test.sh script to put files to Tahoe-Lafs.

---

bash-3.2$ du -sh . 102m

---

bash-3.2$ ls *.JPG |wc -l 61

---

bash-3.2$ cat test.sh
#!/bin/sh

# From Directory listing itself == Directory Write CAP
FW="URI:DIR2:tuz27wvy27ua4mt5lyotllbyke:phzv6ilb5gssi3zy33nki62zcudqjzyv7v7w4qaavwn5kuh2hawa"



X=3456
for I in `ls *.JPG`
	do
curl -T $I  http://10.20.0.151:$X/uri/$FW/$I & 
#echo "curl -T $I  http://10.20.0.151:$X/uri/$FW/$I & "
         X=`expr $X + 1`
        if [ $X -le 3500 ] ; then 
           echo "Submitting $I"
           else X=3456;
        fi  
        done

---

Error returned from curl

UnrecoverableFileError: the directory (or mutable file) could not be retrieved, because there were insufficient good shares. This might indicate that no servers were connected, insufficient servers were connected, the URI was corrupt, or that shares have been lost due to server departure, hard drive failure, or disk corruption. You should perform a filecheck on this object to learn more.

---

Error generated when trying to retrieve known good URI from child:

970-paste.txt​

---

[davidsarah]

Note that the script is trying to upload using a different webapi server instance for each file, contrary to the prime coordination directive.

However, this should probably have caused an UncoordinatedWriteError, rather than UnrecoverableFileError.

[warner]

wow, it sounds like you were actually able to provoke a real UCWE! Well, a real collision, at least.

So, did really none of the PUT commands result in an error? I would have expected at least one of them to emit a UCWE. Re-running the test and sending the output of each curl instance to a separate logfile would help answer this question. Also double-checking that curl emits errors to stdout when it gets a 500 or whatever HTTP error code UCWE maps to.

If you could, please do a file-check (with --verify) on the directory in question. With the dircap you show, the command would be "tahoe check --verify --raw $FW". I'm expecting to see a small number of shares of each version, for several different versions.

The file-check output will tell us, but what were the encoding parameters in use when you ran this test? I know from another ticket you were experimenting with parameters on the order of 40-of-50.. if the dirnodes (and other mutable files) were created with these same parameters, they'd be much more vulnerable to UCWE than with the normal 3-of-10 encoding. If that was a factor here, we might want to consider separate encoding-parameter configs for dirnodes (or perhaps for all mutable files), so that you can use safer 3-of-10 for them and more efficient 40-of-50 for immutable bulk data. (Note that protection from UCWE comes from small "k", whereas the usual reliability against server problems comes from having a large N-k).

(also, incidentally, when pasting large shell transcripts into a Trac page like this one, you should wrap the block with triple-curlies, so that Trac will not try to interpret the comments as WikiFormatting. And please attach other things as trac attachments instead of e.g. codepad links, because a few months from now when somebody comes back to look at this ticket, the pastebin will have expired and the contents lost)

[zooko]

Careful here -- the only safe solution is to coordinate writes. Having different encoding parameters such as a smaller k may reduce the amount of damage to your data when an uncoordinated write is encountered (or it may not -- I vaguely recall that the reasoning about that was surprisingly subtle), but one shouldn't rely on that to protect one's data.

[zooko]

source:docs/specifications/mutable.txt@3696#L48 The Prime Coordination Directive]

[zooko]

Hm, the docs in docs/specifications/mutable.txt@3696#L48 suggest the following four strategies:

• don't give the read-write URI to anyone else. Dirnodes in a private directory generally satisfy this case, as long as you don't use two clients on the same account at the same time
• if you give a read-write URI to someone else, stop using it yourself. An inbox would be a good example of this.
• if you give a read-write URI to someone else, call them on the phone before you write into it
• build an automated mechanism to have your agents coordinate writes. For example, we expect a future release to include a FURL for a "coordination server" in the dirnodes. The rule can be that you must contact the coordination server and obtain a lock/lease on the file before you're allowed to modify it.

Then later they mention that a Tahoe-LAFS gateway automatically serializes requests that go through it to the same mutable file or directory. Perhaps that should be promoted to a fifth strategy: make all your writes to a certain mutable file or directory go through a certain Tahoe-LAFS gateway.

[davidsarah]

Error generated when trying to retrieve known good URI from child