Re: [fuse-devel] stale inodes still used after fuse_lowlevel_notify_inval_entry()

[Han-Wen N. <ha...@gm...>]

On Tue, Sep 13, 2011 at 7:36 PM, Bryan Green <br...@gr...> 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 - ha...@xs... - http://www.xs4all.nl/~hanwen