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@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. Agree. Also external client has modified a file may be a cause for invalidate. > > 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
