On Wed, Oct 19, 2016 at 4:51 AM, Nikolaus Rath <Nikolaus@xxxxxxxx> wrote: > Hello, > > *ping* > > Really no one able to clarify the difference between the FUSE invalidate > and delete dentry requests? It may sound strange to you, but I think the documentation is clear enough. The difference is that in delete case, you *know* that the entry has been deleted and in invalidate case, you may not know what happened to the entry. The specific use cases are implementation specific, but maybe you lost contact with remote server or maybe the remote protocol imposes a timeout for validity or maybe you do not have enough information to figure out if the entry has been deleted and re-created. Invalidate simply means that you no longer know that the entry is valid. > > Best, > -Nikolaus > > On Oct 10 2016, Nikolaus Rath <Nikolaus@xxxxxxxx> wrote: >> On Oct 10 2016, 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... >>> >>> 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). >> >> This sounds reasonable, but what are the reasons? Why does the kernel >> need to be told about a rename in a different way than about a removal? >> Note that we are not transmitting the new name. >> >> How is a rename even technically different from first removing an entry >> and entry and then adding a different one for the same inode? For >> example, suppose I have a network file system and this happens on the >> remote side: >> >> $ echo "contents" > perm_name >> $ ln perm_name old_name >> $ rm old_name >> $ ln perm_name new name >> >> On the local system, does this really need to be signaled to the kernel >> differently than >> >> $ echo "contents" > perm_name >> $ ln perm_name old_name >> $ mv old_name new_name >> >> (Obviously in the file system one is atomic and the other is not, but I >> don't see how this matters for the call to the notify_* function). >> >> >> Also, what is the reason for _delete() falling back to _inval_entry() in >> some conditions? I have trouble coming up with the scenario where this >> is required / helpful. >> >> >> 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.« > > > -- > 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.« > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > -- > fuse-devel mailing list > To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel -- 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
