On Mon, 2016-10-10 at 18:57 +0300, Amir Goldstein wrote: > On Mon, Oct 10, 2016 at 6:55 PM, Michael Theall > <mtheall@xxxxxxxxxxxxxxxxxx> wrote: > > > > 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@xxxxxxx > > > > g> > > > > 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. > Agree. Also external client has modified a file may be a cause for > invalidate. Unless the name has changed, I would use inval_inode() when an external client has changed the 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
