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
