Re: [fuse-devel] fuse internal error: unable to unhash node: 2663128

[Miklos S. <mi...@sz...>]

On Tue, 11 Jan 2011, Gomes, José wrote:
> Hello fuse-devel,
> 
> *
> unique: 8520735, opcode: FORGET (2), nodeid: 2663128, insize: 48
> FORGET 2663128/1
> fuse internal error: unable to unhash node: 2663128
> 
> *
> I have started to get this error message (and fuse crash) on a simple
> read-only filesystem that has otherwise been working fine for three years
> (reason why it uses a pretty old release of fuse). Note sure whether this is
> host-specific because despite my efforts I have not been able to reproduce
> this outside of our production environment. It happens only about once a
> week on the same production host that is pretty loaded at all times. This is
> using *fuse-2.7.3-1, kernel 2.6.18-53.1.21.el5xen, on Centos 5.1*.

You might try upgrading to 2.7.6, there was a bugfix in that area
since 2.7.3:

        * Don't call forget_node() if the lookup was negative and write()
        for the reply returned ENOENT.  Reported by John Haxby


> That specific filesystem implements only *getattr, open, read, release,
> readdir*. It is pretty simple and is backed by an ext3 filesystem, in a
> sense it is just virtualizing some of the underlying ext3 layout and
> presenting it differently. Given that I have no control over the lifecycle
> of inodes, I assume that this is possibly a fuse bug. Of course I am
> planning to rebuild with the latest release of fuse and report back here but
> given how hard it is to reproduce, do you see any specific reason why a
> newer release of fuse might fix the specific issue? Do you see any way that
> something in my implementation might cause this? In my understanding, no
> matter how I implement getattr, open, read, release, readdir, this should
> not happen. Is this assumption correct?

Yes.

> Earlier in the log we can see the regular LOOKUP sequence that gets the
> inode created and I see nothing else unexpected in that log file.

If upgrading doesn't solve the issue, could you please send the whole
logfile (off list, since it's large) for analysis.

Thanks,
Miklos