[Gluster-devel] Client side afr, locking, race condition, simultanous writes, out of sync

[Anand Babu Periasamy]

Now it becomes easier to explain with actual cases and examples.

Your tests are expected to fail. It is a POSIX requirement
for applications to hold locks or synchronize using some
form of IPC/RPC before writing to the same file at same
time.

If you hold a lock and write "one" or "two" to file.txt
your tests will always succeed. If not, the file will
get corrupted. In case of a replicated file system,
corruption can also result in disparate set of data.

We can introduce atomic-writes as an option for AFR
translator. It will avoid disparate writes in case
of corruption, but it still cannot avoid corruption.
It won't be of much use, except taking some performance
hit.

We are open to implementing this option if you think
it is useful to you.

/bin/echo command interpreted by the shell is a complete
process. Shell creates the files without holding any locks.
If you want to hold locks inside shell scripts, you
can either create a .lck file and hold on to it..
or can do a simple trick like this one..
--------------------------------------
client1# echo "one" > file.txt.$(hostname)
client1# mv file.txt.$(hostname) file.txt

client2# echo "two" > file.txt.$(hostname)
client2# mv file.txt.$(hostname) file.txt
--------------------------------------

You are always expected to hold locks and issue writes
in a multi user mode.

--
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:
>> --- Brandon Lamb <brandonlamb at gmail.com> wrote:
>> So a simple 2 server, 2 client, client side afr
>> setup.
>>
>> The clients at the SAME time do:
>>
>> client1 # echo "one" > file.txt
>> client2 # echo "two" > file.txt
> 
> --- gordan at bobich.net wrote:
>> I think the parent directory version getting 
>> bumped up on every create/delete operation 
>> (this would probably require directory locking!) 
>> inside it and using this parent directory version 
>> number at create time of files inside it as the
>> major version number, with the file's own version 
>> number as the minor version number would solve 
>> this, too.
> 
> Perhaps I am missing something, but I fail to see 
> how this could help at all in this situation. Could
> you extrapolate or give more details about how you
> are picturing version #s helping out with this 
> problem.  Here is how I picture version #s is this
> scenario.
> 
>   SubA                  SubB
> 
>   /dir/file             /dir/file
>   v2   v1               v2   v1
> 
>   client1 # echo "one" > file
>   client2 # echo "two" > file
> 
>   /dir/file < one       /dir/file < two
>   v2   v2               v2   v2
> 
>   /dir/file < two       /dir/file < one
>   v2   v3               v2   v3
> 
> Now both subvolumes have the same version #s
> but different file contents.  Where/how are 
> you suggesting a fix to this situation?
> 
> -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