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

[Nikolaus Rath <Nikolaus@rath.org>]

On Oct 31 2016, John Muir <john@jmuir.com> wrote:
>> On 2016.10.08, at 21:37 , Nikolaus Rath <Nikolaus@rath.org> wrote:
>> 
>> 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? 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?
>
>
> These are aimed at networked file-systems where changes can be initiated at the other end.
>
> The first clears the cached data for that dentry, so that next time
> the file lookup occurs the file is still in existence but there is no
> cached data, forcing the request to go down to the user-space
> file-system. This would be used during remote rename.
>
> The second actually removes the dentry in the VFS in the kernel. This
> would be used during remote deletion.

Alright, seems there are as many different opinions on this as there are
replies. So I tried to make sense of the code myself.

I think Miklos and Amir are correct: the only difference between the
functions is a call to fsnotify.

At least as of kernel 4.8, both notify_delete and notify_inval_inode
result in a call to fuse_reverse_inval_entry() in the kernel. And that
function calls fuse_invalidate_attr (to invalidate the attributes of the
parent) and fuse_invalidate_entry (which removes the dentry from the
hash via d_invalidate *and* marks it as stale).

The only difference is that when reverse_inval_entry is entered via
notify_delete, it attempts to call d_delete (after the call to
d_invalidate), which seems to have the effect of only calling
fsnotify_nameremove().

John, are we missing something?

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.«