The Linux FUSE does not perform lookup() on ".." but instead looks up the parent of cwd's dentry within the kernel module itself. In 3.3 we changed the behavior to establish inode on a ".." lookup but neglect dentry establishment (since it will form a loop). You might want to backport 9bd1b291e3e107250b38d05702df7cd751382bdc to release-3.2 if NetBSD FUSE sends ".." lookup.
Avati
On Wed, Aug 8, 2012 at 9:51 PM, Emmanuel Dreyfus <manu@xxxxxxxxxx> wrote:
Hi
Test case: calling getcwd(3) in a directory on NetBSD
- glusterfs release-3.3 has no problem
- glusterfs 3.2.7 has a funny bug when a node TTL is expired *and* if
the getcwd program is stored in the glusterfs volume.
# cd /gfs/manu/bugB4 && /gfs/manu/getcwd/getcwd && sleep 2 && \
/gfs/manu/getcwd/getcwd
getcwd = "/gfs/manu/bugB4"
getcwd = "(null)"
# cd /gfs/manu/bugB4 && /tmp/getcwd && sleep 2 && /tmp/getcwd
getcwd = "/gfs/manu/bugB4"
getcwd = "/gfs/manu/bugB4"
When it fails the client logs say:
[2012-08-09 06:45:37.338851] W [inode.c:180:__foreach_ancestor_dentry]
0-: per dentry fn returned 1
[2012-08-09 06:45:37.339021] C [inode.c:232:__is_dentry_cyclic]
0-gfs/inode: detected cyclic loop formation during inode linkage.
inode (-5514238854638478444/20958215-feaa-4648-acde-5f3e8da776e5) l
linking under itself as ..
[2012-08-09 06:45:37.339112] W [inode.c:844:inode_lookup] 0-: inode
not found
Is that a bug in glusterfs 3.2.7 or an inaccuracy in NetBSD FUSE? Here
is getcwd sources for anyone willing to test:
/* cc -o getcwd getcwd.c */
#include <unistd.h>
#include <stdio.h>
#include <sys/param.h>
int
main(void)
{
char buf[MAXPATHLEN + 1];
(void)printf("getcwd = \"%s\"\n", getcwd(buf, MAXPATHLEN));
return 0;
}
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@xxxxxxxxxx
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
https://lists.nongnu.org/mailman/listinfo/gluster-devel