On Oct 31 2016, John Muir <john@xxxxxxxxx> wrote:
>> On 2016.10.08, at 21:37 , Nikolaus Rath <Nikolaus@xxxxxxxx> 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.«
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
