From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:37146 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752553AbcJJPzb (ORCPT ); Mon, 10 Oct 2016 11:55:31 -0400 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9AFres2064194 for ; Mon, 10 Oct 2016 11:55:25 -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 260cc3csbc-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 10 Oct 2016 11:55:24 -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 09:55:23 -0600 Subject: Re: [fuse-devel] Difference between invalidating and deleting dentry From: Michael Theall To: Nikolaus Rath , Amir Goldstein Cc: fuse-devel@lists.sourceforge.net, linux-fsdevel , Miklos Szeredi Date: Mon, 10 Oct 2016 10:55:18 -0500 In-Reply-To: <87a8ecqkbp.fsf@vostro.rath.org> References: <87h98mxhlk.fsf@vostro.rath.org> <87a8ecqkbp.fsf@vostro.rath.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <1476114918.7959.3.camel@linux.vnet.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 > > 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. Regards, Michael Theall