From: Nikolaus Rath <Nikolaus@rath.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: fuse-devel@lists.sourceforge.net,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Miklos Szeredi <miklos@szeredi.hu>
Subject: Re: [fuse-devel] Difference between invalidating and deleting dentry
Date: Mon, 10 Oct 2016 08:45:30 -0700 [thread overview]
Message-ID: <87a8ecqkbp.fsf@vostro.rath.org> (raw)
In-Reply-To: <CAOQ4uxhaBO59-CVHF9udT9CAFbALyYaQxiJyN8csjOi3ud-6MA@mail.gmail.com> (Amir Goldstein's message of "Mon, 10 Oct 2016 11:16:25 +0300")
Hi Amir,
On Oct 10 2016, Amir Goldstein <amir73il@gmail.com> wrote:
> Hi Nikolaus,
>
> On Sun, Oct 9, 2016 at 7:37 AM, Nikolaus Rath <Nikolaus@rath.org> 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
--
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.«
next prev parent reply other threads:[~2016-10-10 15:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-09 4:37 Difference between invalidating and deleting dentry Nikolaus Rath
2016-10-10 8:16 ` [fuse-devel] " Amir Goldstein
2016-10-10 15:45 ` Nikolaus Rath [this message]
2016-10-10 15:55 ` Michael Theall
2016-10-10 15:57 ` Amir Goldstein
2016-10-10 16:11 ` Michael Theall
2016-10-10 16:10 ` Nikolaus Rath
2016-10-19 1:51 ` Nikolaus Rath
2016-10-19 5:53 ` Amir Goldstein
2016-10-19 8:01 ` Miklos Szeredi
2016-10-19 8:32 ` Amir Goldstein
2016-10-19 8:38 ` Miklos Szeredi
2016-10-19 21:00 ` Nikolaus Rath
2016-10-19 20:55 ` [fuse-devel] " Nikolaus Rath
2016-10-31 14:36 ` John Muir
2016-11-01 20:21 ` Nikolaus Rath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a8ecqkbp.fsf@vostro.rath.org \
--to=nikolaus@rath.org \
--cc=amir73il@gmail.com \
--cc=fuse-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.