[Gluster-users] Bizarre GlusterFS "coherency" issue

[Lei Zhang]

Hi,

I've been chasing down a GlusterFS issue for a while to no avail. We use
2.0.9, restarting client glusterfs does not fix the problem, restarting
server glusterfs does fix the problem. I wonder if this issue is a bug; if
it is a bug, is it fixed in 3.0.4; if it is not fixed, is there a
work-around other than restarting glusterfs server.

*Setup*: 2-node cluster: one glusterfs server, the other as client.
*What I did*: on the server node, remove a tree of files then add the same
tree back through untar a tarball
*Problem*: server can see the tree fine, but sometimes client cannot.

Relevant server log messages:
[2010-05-11 12:51:00] D [server-dentry.c:242:__do_path_resolve_cbk] brick:
looked up for /web-apps/testphp/temp-production/info/control
(329772/control)
[2010-05-11 12:51:00] D [server-helpers.c:96:server_loc_fill] brick: paths
differ for inode(329938): client path =
/web-apps/testphp/temp-production/info/control. dentry path =
/logging/staged/scraper.1273607423.2.dat/temp-production/info/control
[2010-05-11 12:51:00] E [posix.c:277:setgid_override] [storage/posix]: lstat
on parent directory
(/gluster-srv/logging/staged/scraper.1273607423.2.dat/temp-production/info)
failed: Not a directory
[2010-05-11 12:51:00] D [server-protocol.c:2016:server_open_cbk] server:
2968: OPEN
/logging/staged/scraper.1273607423.2.dat/temp-production/info/control
(329938) ==> -20 (Success)

Relevant client log messages:
[2010-05-11 12:51:00] D [client-protocol.c:4913:client_lookup_cbk] remote:
LOOKUP 327048/testphp (/web-apps/testphp): inode number changed from 329508
to 329535
[2010-05-11 12:51:00] D [fuse-bridge.c:302:need_fresh_lookup] fuse-bridge:
revalidate of /web-apps/testphp failed *(Stale NFS file handle)*
[2010-05-11 12:51:00] W [fuse-bridge.c:645:fuse_fd_cbk] glusterfs-fuse:
7201: OPEN() /web-apps/testphp/temp-production/info/control => -1 (Success)

Appreciate any insight.
Lei