Folks: I posted some thoughts to #1755. If you're interested in distributed systems, please read and comment! I posted an argument for why distributed, end-to-end, two-phase commit will probably work fine for LAFS's purposes even though it has gained a well-deserved reputation for "not scaling up to the Internet" in other contexts. (Hint: the answer is, of course, that we're demanding less of it than most systems do.) Unfortunately I didn't yet get around to explaining what we actually want it for. I remember there being at least two different reasons why I really wanted end-to-end two-phase-commit in the LAFS storage protocol. One reason has to do with uploading large mutables and making modifications to large mutables, without asking any computer to "buffer up" all the changes so that it can apply them all quickly, and without opening a large window of time in which a failure in any of several places will leave a corrupted mutable share. The other reason, which I remember less precisely, has to do with multiple writers sharing write-access to the same mutable file or directory. LAFS currently handles that use case very badly. I think e2e 2PC can do better, handling write-collisions with a clean failure ("no can do!") instead of, as it currently does, with potential data loss. At least in almost all cases. But even so, multiple uncoordinated writes to the same resource still have to be held down to a low frequency and a small number of uncoordinated writers. A key insight into all this is that you should use shared access to LAFS's mutables as sparingly as possible, and instead manage almost all of your state with immutables and with single-writer mutables. A great example of this design pattern is the new design we came up with for Dropbox-like functionality on top of Tahoe-LAFS. That synthesizes a "magic folder" like Dropbox from the perspective of the user, but does so without *any* concurrent writes to a shared mutable. Instead, every writer has their own single-writer mutable and the client is responsible for reading all the mutables and synthesizing the result as those mutables get changed by their respective writers. Unfortunately the details of that design are sitting in a queue of "Notes From the Tahoe-LAFS Weekly Dev Call" that I am supposed to write up and post to this list ASAP... Regards, Zooko https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1755# 2-phase commit _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE