id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
345	document write coordination	zooko	warner	"We've been trying to figure out how to deal with this issue on the tahoe-dev list.  Most recently, we thought that uncoordinated writes would happen infrequently, and that even when it arose permanent data loss would happen very rarely, so it would be okay to rely on this probability of safety for now, rather than alternatives that would negate a planned allmydata.com product feature (shared writeable folder), or require more development work (lock server).

However, just now Brian and I realized that our current plan for ""update a directory"" would have a 50% chance of one of the two colliding updates silently disappearing, where a collision happens any time two directory-update processes (which can be between about 4 and 40 seconds) overlap.

This is therefore quite a likely occurrence, and requires something to be done.

My meta-engineering belief at this point is:

The fact that we didn't realize this until just now shows that we don't really understand how Tahoe behaves under uncoordinated writes, and so for the imminent Tahoe (LAUGFS) v0.9.0 release we should continue to require The Prime Directive of Uncoordinated Writes: ""Don't Do That"", and for the Allmydata.com 3.0 release we should implement some method or other of Not Doing That.  (Such as a simple lock server.)


Here's some recent history:

We think there is a problem:

http://allmydata.org/pipermail/tahoe-dev/2008-March/000433.html
http://allmydata.org/pipermail/tahoe-dev/2008-March/000436.html

We think we have a sufficiently safe solution:

http://allmydata.org/pipermail/tahoe-dev/2008-March/000438.html

and just now, on the phone, Brian and I agreed that the solution that we thought we had is not sufficiently safe."	defect	closed	major	1.1.0	unknown	0.8.0	fixed		booker