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.

Jan