[Gluster-devel] Client side AFR race conditions?

[Martin Fick]

--- Anand Babu Periasamy <ab at gnu.org.in> wrote:

> When multiple applications write to a same file, it
> is really application's responsibility to handle 
> coherency using POSIX locks or some form of IPC/RPC 
> mechanism.  Even without AFR, file system's do not 
> guarantee order of writes and hence integrity of 
> data. When AFR is inserted, this corruption may
> lead to disparate set of data other than overwrites.
> 
> It shouldn't be seen as an issue with AFR. If
> applications handle coherency, AFR will work fine.
It
> is possible to introduce atomic-write option (locked

> writes) in AFR, but it is useless, because it still 
> cannot avoid corruption because one application 
> overwrote the data of the other, without holding a 
> lock.
> 
> In summary, AFR doesn't have race condition.

I'm sorry, but I disagree.  I do not think that you
understand the full problem.  The issue is not one of
application coherency but simply one of ensuring that
both copies have the same data.  With the current
implementation I cannot guarantee that I get my good
or my bad data consistently, on every read I could get
a different answer, as many different answers as there
are subvolumes.  It really is a split brain issue.  I
am not asking for ordered writes, simply that the
writes be the same on all subvolumes.

In fact, I really should extend the question and ask,
how does AFR handle locking?  Does it ensure that all
subvolumes are locked?  I assume it does, but the next
question is, what does it do about potential infinite
locks if clients die?  Does is detect a downed client
and release the lock?

-Martin



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ