Re: [fuse-devel] Difference between invalidating and deleting dentry

[Michael Theall <mtheall@linux.vnet.ibm.com>]

On Mon, 2016-10-10 at 18:57 +0300, Amir Goldstein wrote:
> On Mon, Oct 10, 2016 at 6:55 PM, Michael Theall
> <mtheall@linux.vnet.ibm.com> wrote:
> > 
> > On Mon, 2016-10-10 at 08:45 -0700, Nikolaus Rath wrote:
> > > 
> > > Hi Amir,
> > > 
> > > On Oct 10 2016, Amir Goldstein <amir73il@gmail.com> wrote:
> > > > 
> > > > 
> > > > Hi Nikolaus,
> > > > 
> > > > On Sun, Oct 9, 2016 at 7:37 AM, Nikolaus Rath <Nikolaus@rath.or
> > > > g>
> > > > wrote:
> > > > > 
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > I just added an example to FUSE that illustrates use of the
> > > > > fuse_lowlevel_notify_inval_entry() function. However, when
> > > > > writing it I
> > > > > realized that I don't actually fully understand how this
> > > > > function
> > > > > differs from fuse_lowlevel_notify_delete(). Could someone
> > > > > shed
> > > > > some
> > > > > light on this?
> > > > > 
> > > > > Currently, the FUSE documentation says:
> > > > > 
> > > > > fuse_lowlevel_notify_inval_entry:
> > > > >    Notify to invalidate parent attributes and the dentry
> > > > > matching
> > > > >    parent/name
> > > > > 
> > > > > fuse_lowlevel_notify_delete:
> > > > >    Notify to invalidate parent attributes and delete the
> > > > > dentry
> > > > > matching
> > > > >    parent/name if the dentry's inode number matches child
> > > > > (otherwise it
> > > > >    will invalidate the matching dentry).
> > > > > 
> > > > > 
> > > > > But what exactly is the difference between deleting and
> > > > > invalidating a
> > > > > dentry?
> > > > That is the difference:
> > > > 
> > > > /*
> > > >  * d_drop() unhashes the entry from the parent dentry hashes,
> > > > so
> > > > that it won't
> > > >  * be found through a VFS lookup any more. Note that this is
> > > > different from
> > > >  * deleting the dentry - d_delete will try to mark the dentry
> > > > negative if
> > > >  * possible, giving a successful _negative_ lookup, while
> > > > d_drop
> > > > will
> > > >  * just make the cache lookup fail.
> > > >  */
> > > Alright, so at this point I thought I understood the difference
> > > and
> > > got
> > > ready to update the documentation, but then you got me very
> > > confused:
> > > 
> > > > 
> > > > 
> > > > But since fuse_lowlevel_notify_delete does among other things:
> > > > d_invalidate->...d_drop()
> > > > d_delete()
> > > > 
> > > > You may still ask yourself what is the purpose of d_delete()
> > > > after
> > > > d_drop(),
> > > > because there is no cache entry to make negative...
> > > So, in other words, FUSE's notify_delete will *not* store a
> > > negative
> > > dentry, but will just drop the dentry?
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > In each case, isn't the resulting behavior the same, in that
> > > > > the
> > > > > next time someone tries to access this
> > > > > (parent_inode,entry_name)
> > > > > combination a lookup() request will be send to the FUSE
> > > > > process?
> > > > You are right about the next lookup behavior being the same,
> > > > but
> > > > there
> > > > are other things that d_delete() does which d_invalidate does
> > > > not,
> > > > which
> > > > are important, like calling fsnotify_nameremove() and update
> > > > the
> > > > cached
> > > > inode and dentry that are referenced by open files.
> > > Hmm. So when should one use notify_delete() and when
> > > notify_inval_entry()? I understand there is a difference, but I'm
> > > uncertain about the practical consequences...
> > > 
> > > 
> > > Thanks!
> > > -Nikolaus
> > Hi Nikolaus,
> > 
> > It sounds to me like you want to use notify_delete() for an
> > unlink/rmdir and you want to use notify_inval_entry for a rename()
> > (maybe delete the old name and invalidate the new name). You would
> > want
> > to do this when you know either of these things has happened
> > outside
> > the knowledge of the kernel, e.g. you know that an external client
> > has
> > deleted/renamed a file.
> Agree. Also external client has modified a file may be a cause for
> invalidate.

Unless the name has changed, I would use inval_inode() when an external
client has changed the file.

Regards,
Michael Theall