gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] Client side AFR race conditions?


From: Anand Babu Periasamy
Subject: Re: [Gluster-devel] Client side AFR race conditions?
Date: Fri, 02 May 2008 18:39:56 -0700
User-agent: Mozilla-Thunderbird 2.0.0.12 (X11/20080420)

Hi Martin,

If application doesn't use locking in a multi-user mode, data
can be corrupted with or without AFR. With AFR in place, corruption
can also result in disparate set of data, other than losing the order
of writes. No file system can guarantee integrity, if applications
do not synchronize writes in multiuser mode.

Even if we introduce atomic writes within AFR, it still doesn't
fix application's bugs. It will only slow down writes for well
behaved applications.

--
Anand Babu Periasamy
GPG Key ID: 0x62E15A31
Blog [http://ab.freeshell.org]
The GNU Operating System [http://www.gnu.org]
Z RESEARCH Inc [http://www.zresearch.com]



Martin Fick wrote:
--- Anand Babu Periasamy <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]