From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com ([66.111.4.25]:37514 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752676AbcJSBvE (ORCPT ); Tue, 18 Oct 2016 21:51:04 -0400 From: Nikolaus Rath To: fuse-devel@lists.sourceforge.net, linux-fsdevel , Miklos Szeredi Subject: Re: [fuse-devel] Difference between invalidating and deleting dentry References: <87h98mxhlk.fsf@vostro.rath.org> <87a8ecqkbp.fsf@vostro.rath.org> <1476114918.7959.3.camel@linux.vnet.ibm.com> <871szoqj6l.fsf@vostro.rath.org> Date: Tue, 18 Oct 2016 18:51:01 -0700 In-Reply-To: <871szoqj6l.fsf@vostro.rath.org> (Nikolaus Rath's message of "Mon, 10 Oct 2016 09:10:10 -0700") Message-ID: <87k2d53y4a.fsf@vostro.rath.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 wrote: > On Oct 10 2016, Michael Theall wrote: >> On Mon, 2016-10-10 at 08:45 -0700, Nikolaus Rath wrote: >>> Hi Amir, >>>=20 >>> On Oct 10 2016, Amir Goldstein wrote: >>> >=20 >>> > Hi Nikolaus, >>> >=20 >>> > On Sun, Oct 9, 2016 at 7:37 AM, Nikolaus Rath >>> > wrote: >>> > >=20 >>> > > Hello, >>> > >=20 >>> > > 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? >>> > >=20 >>> > > Currently, the FUSE documentation says: >>> > >=20 >>> > > fuse_lowlevel_notify_inval_entry: >>> > > =C2=A0=C2=A0=C2=A0Notify to invalidate parent attributes and the de= ntry matching >>> > > =C2=A0=C2=A0=C2=A0parent/name >>> > >=20 >>> > > fuse_lowlevel_notify_delete: >>> > > =C2=A0=C2=A0=C2=A0Notify to invalidate parent attributes and delete= the dentry >>> > > matching >>> > > =C2=A0=C2=A0=C2=A0parent/name if the dentry's inode number matches = child >>> > > (otherwise it >>> > > =C2=A0=C2=A0=C2=A0will invalidate the matching dentry). >>> > >=20 >>> > >=20 >>> > > But what exactly is the difference between deleting and >>> > > invalidating a >>> > > dentry? >>> > That is the difference: >>> >=20 >>> > /* >>> > =C2=A0* d_drop() unhashes the entry from the parent dentry hashes, so >>> > that it won't >>> > =C2=A0* be found through a VFS lookup any more. Note that this is >>> > different from >>> > =C2=A0* deleting the dentry - d_delete will try to mark the dentry >>> > negative if >>> > =C2=A0* possible, giving a successful _negative_ lookup, while d_drop >>> > will >>> > =C2=A0* just make the cache lookup fail. >>> > =C2=A0*/ >>> 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: >>>=20 >>> >=20 >>> > But since fuse_lowlevel_notify_delete does among other things: >>> > d_invalidate->...d_drop() >>> > d_delete() >>> >=20 >>> > 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? >>> >=20 >>> > > 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... >>=20 >> 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 > > > --=20 > GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F > Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F > > =C2=BBTime flies like an arrow, fruit flies like a Banana.= =C2=AB --=20 GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F =C2=BBTime flies like an arrow, fruit flies like a Banana.=C2= =AB