Han-Wen Nienhuys | 16 Sep 23:14 2011

Re: stale inodes still used after fuse_lowlevel_notify_inval_entry()

On Tue, Sep 13, 2011 at 7:36 PM, Bryan Green <bryan <at> grid-net.com> wrote:
> I am trying to implement internal removal of a directory tree from
> inside a fuse application (i.e., the tree reflects an internal dynamic
> topology created by the application, and cannot be modified externally,
> sort of like sysfs), but I am seeing fuse using inodes that should have
> been marked as invalidated (because they were "removed" by the
> application).  I'd like to know if I am using the invalidation routines
> incorrectly.
> The behavior is pretty much identical to what is described here, in
> which fuse does not seem to respect the reply to a lookup:
> http://comments.gmane.org/gmane.comp.file-systems.fuse.devel/9523
> Specifically,  I have a directory structure that looks something like this:
> root (ino=1)
>    subdir1 (ino=2)
>       subdir2 (ino=3)
>           subdir3 (ino=4)
> I issue fuse_lowlevel_notify_inval_entry(parent_ino=2,name="subdir2")
> Later, I see a lookup request come in from fuse, for which I return an
> error:
> lookup(parent_ino = 2, name = "subdir2")
>    -> fuse_reply_err(ENOENT)
> But then, fuse tries to perform a lookup on inode 3 anyway:
> lookup(parent_ino = 3, name = "subdir3")
> So why is fuse keeping inode 3 around, and why does it use it after the
> first lookup failed?
> Isn't that a bug?  Or am I missing something?

Inode 3 could be referenced from another directory or still be opened
as a file, so invalidating the entry should not by definition require
the inode to become unknown. Have you tried invalidating inode 3's
attributes too ?

(I don't know much about the kernel code, though)


Han-Wen Nienhuys - hanwen <at> xs4all.nl - http://www.xs4all.nl/~hanwen

BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
fuse-devel mailing list
fuse-devel <at> lists.sourceforge.net