(Illustration by Gaich Muramatsu)
On Tue, Jul 08, 2003 at 03:27:41PM +0100, lou wrote: > In some email I received from Peter Sch?ller <peter.schuller_at_infidyne.com> on Tue, 8 Jul 2003 17:20:43 +0200, wrote: > > > Hm I was wonder if check is done when: > > > > > > client 1: open(file,O_RW); > > > client 2: open(file,O_RW); > > > > > > wont this lead to corruption which will take the volume offline? > > > > It leads to a client/server conflict on one client (or perhaps even both?). > > See: ... > > http://www.coda.cs.cmu.edu/doc/html/coda-howto-4.html#ss4.7 > > > > (If I am being incorrect/misleading, someone please correct me.) > > So I was wondering, wont it be good if the server actually checks if > the file is open rw, only when the volume is Connected in diconnected > mode this check should be skipped. But there is no way to guarantee that a client is not disconnected, which makes the 'protection' useless. (Write-)disconnected operation happens not only as a result of physically pulling a wire, or a crashed server. Reintegration actually works as a load-balancer, we can optimize away operations and it is more efficient to push a large batch of operations in a single transaction. So 'disconnected' operation kicks in whenever the network performance deteriorates, which could be caused by backups, p2p sharers, or a bunch of people grabbing a copy of the latest redhat.iso images. It also is useful whenever the server becomes overloaded, writes are postponed, useless operations are optimized away and the rest is committed in large batches. In the mean time the servers only have to deal with read requests, and we can server many readers at the same time. As a result, anyone who writes a program that assumes that concurrent open-for-writes will work reliably and will not result in conflicts will see their application fail miserably as soon as client1 or client2 switches to writeback caching for any reason. AFS2 uses a different solution, 'last writer wins' semantics, if client1 closes the file first it loses those updates as soon as client2 closes the file. AFS3 messes it up really well, because of the 'partial file' fetch functionality, client2 actually fetches the updates made by client1 as soon as it receives a callback. So it just lost whatever updates were actually made at client2. It then writes out the data with the inode size it had originally on client2. So imagine the following scenario, AFS3 concurrent O_RDWR scenario client2 foo = open('foo', O_RDWR); write(foo, "a"); client1 foo = open('foo', O_RDWR); write(foo, "test"); close(foo); /* foo now contains "test" */ client2 close(foo); /* surprise! foo now contains "t" */ I actually like it that Coda gives me a conflict in these situations, at least I get to keep both pieces. JanReceived on 2003-07-08 11:41:17