[Gluster-devel] Client side AFR race conditions?

[Krishna Srinivas]

Hi Martin,

This is a known issue with the client side AFR. We can solve this by locking
but there will be performance hit. Ofcourse if applications lock themselves
then all will be fine. I feel we can have it as an option to disable the locking
in case users are more concerned about performance.

Do you have any suggestions?

Krishna

On Fri, May 2, 2008 at 3:46 AM, Martin Fick <mogulguy at yahoo.com> wrote:
>
>  --- Gordan Bobic <gordan at bobich.net> wrote:
>
>  > Martin Fick wrote:
>  > > I am curious, is client side AFR susceptible to
>  > race
>  > > conditions on writes?  If not, how is this
>  > mitigated?
>  > >
>  > >
>  > > In other words, what prevents conflicts when
>  > client A
>  > > & B both write to the same file?  Could A's write
>  > to
>  > > subvolume A succeed before B's write to subvolume
>  > A,
>  > > and at the same time B's write to subvolume B
>  > succeed
>  > > before A's write to subvolume B?  If so, isn't
>  > this
>  > > somewhat similar to a split brain operation?  Is
>  > there
>  > > some form a transaction layer using file version
>  > #s
>  > > that prevents this?
>  >
>  > I would imagine the same thing happens as would
>  > happen on a local FS.
>
>
>  Well, it can't happen on a local FS.  On a local FS
>  one of the clients would win.  While you may not know
>  which one will win, with the scenario I am describing
>  they both win but on different subvolumes.  This would
>  leave subvolume A with client B having won and
>  subvolume B with client A having won.  Now depending
>  on which subvolume I read from I will get a different
>  answer.  With a local FS I can only get one answer.
>  Does that make sense?
>
>
>  -Martin
>
>
>
>       ____________________________________________________________________________________
>  Be a better friend, newshound, and
>  know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
>
>  _______________________________________________
>
>
> Gluster-devel mailing list
>  Gluster-devel at nongnu.org
>  http://lists.nongnu.org/mailman/listinfo/gluster-devel
>