Hello all, I have a question for people with indepth glusterfs code knowledge. Lets assume I have a 2 brick distributed setup with one client and a mounted path /gluster. brick1 exports /brick1, brick2 exports /brick2 I do the following in bash: touch /tmp/testfile chown dummyuser:dummygroup /tmp/testfile mv /tmp/testfile /gluster/dir1/ mv /gluster/dir1/testfile /gluster/dir2/ this works most of the time. But sometimes I see this on one brick (not always the same brick): [2012-08-23 20:30:01] E [posix.c:1515:posix_chown] posix: lchown on /dir1/testfile failed: No such file or directory [2012-08-23 20:30:01] E [posix.c:1461:posix_chmod] posix: chmod on /dir1/testfile failed: No such file or directory [2012-08-23 20:30:01] E [posix.c:1636:posix_utimens] posix: utimes on /brick1/dir1/testfile failed: No such file or dir Of course the last line can also be [2012-08-23 20:30:01] E [posix.c:1636:posix_utimens] posix: utimes on /brick1/dir2/testfile failed: No such file or dir depending on the brick. If you look at brick1/2 afterwards you see that on the brick with these errors testfile is own by root:root, whereas client shows correct owner dummyuser:dummygroup, just like the brick without the error does. The problem is not solved by selfheal. Now my question is: is this a solved bug? Can someone point me to a patch? I am not using the latest glusterfs and don't want to. I am only looking for information to backport the bugfix. The client uses replicate-iocache-writebehind-iothreads btw. The bug obviously shows that mv across glusterfs does not work atomic and the fs is not even serializing fs actions concerning the same file. -- Regards, Stephan
