Hi Nikolaus, On Sun, Oct 9, 2016 at 7:37 AM, Nikolaus Rath <Nikolaus@xxxxxxxx> 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. */ 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... > 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. Cheers, Amir. -- 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
