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.«
--
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
