Re: Client side afr, locking, race condition, simultanous writes, out of sync

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

 



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@xxxxxxxxx> 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@xxxxxxxxxx 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@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux