From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:36794 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752078AbcJJQMw (ORCPT ); Mon, 10 Oct 2016 12:12:52 -0400 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9AGBoTL118362 for ; Mon, 10 Oct 2016 12:12:04 -0400 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by mx0a-001b2d01.pphosted.com with ESMTP id 260cx941c1-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 10 Oct 2016 12:12:03 -0400 Received: from localhost by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 10 Oct 2016 10:12:02 -0600 Subject: Re: [fuse-devel] Difference between invalidating and deleting dentry From: Michael Theall To: Amir Goldstein Cc: Nikolaus Rath , fuse-devel@lists.sourceforge.net, linux-fsdevel , Miklos Szeredi Date: Mon, 10 Oct 2016 11:11:57 -0500 In-Reply-To: References: <87h98mxhlk.fsf@vostro.rath.org> <87a8ecqkbp.fsf@vostro.rath.org> <1476114918.7959.3.camel@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <1476115917.7959.5.camel@linux.vnet.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, 2016-10-10 at 18:57 +0300, Amir Goldstein wrote: > On Mon, Oct 10, 2016 at 6:55 PM, Michael Theall > wrote: > > > > On Mon, 2016-10-10 at 08:45 -0700, Nikolaus Rath wrote: > > > > > > Hi Amir, > > > > > > On Oct 10 2016, Amir Goldstein wrote: > > > > > > > > > > > > Hi Nikolaus, > > > > > > > > On Sun, Oct 9, 2016 at 7:37 AM, Nikolaus Rath > > > g> > > > > 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 > > Hi Nikolaus, > > > > 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). You would > > want > > to do this when you know either of these things has happened > > outside > > the knowledge of the kernel, e.g. you know that an external client > > has > > deleted/renamed a file. > Agree. Also external client has modified a file may be a cause for > invalidate. Unless the name has changed, I would use inval_inode() when an external client has changed the file. Regards, Michael Theall