Gluster users - Nov 2008 - "UNLINK [...] returned NULL inode" message in client log

Hello all,

Lately i've been seeing the following messages over and over again in my 
client logs :

2008-11-17 01:52:51 E [fuse-bridge.c:1163:fuse_unlink] glusterfs-fuse: 
143141519: UNLINK /directory/sub-directory/file.ext (fuse_loc_fill() 
returned NULL inode)

This type of message has occured over 3000 (not a typo) times since 14 
November alone, so it's getting hard to ignore.  It seems to occur 
"randomly", which is to say that there appears to be no pattern to the
type of file or the timing of the message.

I don't know what it means, exactly, so i'm not even sure if it's 
causing problems ; however, there have been some complaints about files 
which are "empty" on the client, so perhaps the two are related.

Any pointers on what this message means, what sort of effects might be 
exhibited by the given condition, and how i might go about fixing it are 
more than welcome. :)

The vitals :

(clients and servers ...)
$ glusterfs --version | head -n 2
glusterfs 1.3.12 built on Oct 23 2008 14:26:16
Repository revision: glusterfs--mainline--2.5--patch-797
$ rpm -qa | grep fuse
fuse-2.7.3glfs10-1
fuse-libs-2.7.3glfs10-1

(clients ...)
$ uname -r -i
2.6.24.4 x86_64
$ cat /etc/redhat-release
Fedora release 8 (Werewolf)

(servers ...)
$ uname -r -i
2.6.25.10-86.fc9.i686 i386
$ cat /etc/redhat-release
Fedora release 9 (Sulphur)

Client config :
http://glusterfs.pastebin.com/m48b7dd28

Server config :
http://glusterfs.pastebin.com/m45feb982

Thanks, all !


-- 
Daniel Maher <dma+gluster AT witbe DOT net>

Daniel Maher wrote:
> Hello all,
> 
> Lately i've been seeing the following messages over and over again in
my
> client logs :
> 
> 2008-11-17 01:52:51 E [fuse-bridge.c:1163:fuse_unlink] glusterfs-fuse: 
> 143141519: UNLINK /directory/sub-directory/file.ext (fuse_loc_fill() 
> returned NULL inode)
Hello once again :)

I posted this in November, but did not receive any responses at the 
time.  With all the talk of mixing 32 and 64-bit systems, it occurred to 
me that perhaps there's a link between word size (and the exceeding 
thereof), and this error.

Is it possible that my 64-bit clients are trying to assign file 
attributes which are too large for my 32-bit servers to deal with, and 
if so, could that result in the error noted above ?


-- 
Daniel Maher <dma+gluster AT witbe DOT net>