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

[Nikolaus R. <Nik...@ra...>]

On Oct 10 2016, Michael Theall <mt...@li...> wrote:
> On Mon, 2016-10-10 at 08:45 -0700, Nikolaus Rath wrote:
>> Hi Amir,
>> 
>> On Oct 10 2016, Amir Goldstein <ami...@gm...> wrote:
>> > 
>> > Hi Nikolaus,
>> > 
>> > On Sun, Oct 9, 2016 at 7:37 AM, Nikolaus Rath <Nik...@ra...>
>> > 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...
> 
> 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).

This sounds reasonable, but what are the reasons? Why does the kernel
need to be told about a rename in a different way than about a removal?
Note that we are not transmitting the new name.

How is a rename even technically different from first removing an entry
and entry and then adding a different one for the same inode? For
example, suppose I have a network file system and this happens on the
remote side:

$ echo "contents" > perm_name
$ ln perm_name old_name
$ rm old_name
$ ln perm_name new name

On the local system, does this really need to be signaled to the kernel
differently than

$ echo "contents" > perm_name
$ ln perm_name old_name
$ mv old_name new_name

(Obviously in the file system one is atomic and the other is not, but I
don't see how this matters for the call to the notify_* function).


Also, what is the reason for _delete() falling back to _inval_entry() in
some conditions? I have trouble coming up with the scenario where this
is required / helpful.


Best,
-Nikolaus


-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«