+++ This bug was initially created as a clone of Bug #765563 +++ From gluster-devel mailing list After machine2 replaced the node, machine1 gets the new inode number using READDIR, but the inode number returned by LOOKUP is the one for the deleted node. The only way to work it around is to unmount and remount the filesystem. machine1# cd /gfs/stale && ls -l total 4 drwxr-xr-x 2 root wheel 2048 Nov 27 06:47 a machine2# cd /gfs/stale && cp -r a b && rm -Rf a && mv b a machine1# ls -l ls: a: No such file or directory machine1# cd a machine1# ls ls: .: No such file or directory machine1# cd /gfs/stale machine1# ls -l ls: a: No such file or directory --- Additional comment from amarts on 2011-12-01 02:38:40 EST --- Is this tried to reproduce? I see that fuse-bridge already has a mechanism to re-validate the inodes. Please try to reproduce on master branch, and confirm the behavior.
Could you guys please point us to the fix here?
Anush, the changes from GFID backend and proper fd migrations should fix these things. There are specific bugs for these enhancement and hence no mention of any patches/fixes here. Please see that in 3.4.x releases (for now qa) this is fixed. None of our testing yeild this behavior anymore.
Verified with glusterfs-fuse-3.4.0.17rhs-1.el6rhs.x86_64
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1262.html