Hello,
*ping*
Really no one able to clarify the difference between the FUSE invalidate
and delete dentry requests?
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.«
--
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
