On Mon, 2016-10-10 at 08:45 -0700, Nikolaus Rath wrote: > Hi Amir, > > On Oct 10 2016, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > 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. > > */ > 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. Regards, Michael Theall -- 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
