|
From: | Anand Babu Periasamy |
Subject: | Re: [Gluster-devel] Client side afr, locking, race condition, simultanous writes, out of sync |
Date: | Fri, 09 May 2008 04:35:14 -0700 |
User-agent: | Mozilla-Thunderbird 2.0.0.12 (X11/20080420) |
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 <address@hidden> 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--- address@hidden 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. Couldyou extrapolate or give more details about how youare picturing version #s helping out with this problem. Here is how I picture version #s is thisscenario. 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 #sbut 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 address@hidden http://lists.nongnu.org/mailman/listinfo/gluster-devel
[Prev in Thread] | Current Thread | [Next in Thread] |