From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com ([66.111.4.26]:36699 "EHLO out2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752726AbcKAUVI (ORCPT ); Tue, 1 Nov 2016 16:21:08 -0400 From: Nikolaus Rath To: John Muir Cc: fuse-devel , Linux-Fsdevel , Miklos Szeredi Subject: Re: [fuse-devel] Difference between invalidating and deleting dentry References: <87h98mxhlk.fsf@vostro.rath.org> Date: Tue, 01 Nov 2016 13:21:02 -0700 In-Reply-To: (John Muir's message of "Mon, 31 Oct 2016 07:36:59 -0700") Message-ID: <87y413gde9.fsf@thinkpad.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: On Oct 31 2016, John Muir wrote: >> On 2016.10.08, at 21:37 , Nikolaus Rath wrote: >>=20 >> fuse_lowlevel_notify_inval_entry: >> Notify to invalidate parent attributes and the dentry matching >> parent/name >>=20 >> 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). >>=20 >>=20 >> But what exactly is the difference between deleting and invalidating a >> 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? > > > These are aimed at networked file-systems where changes can be initiated = at the other end. > > The first clears the cached data for that dentry, so that next time > the file lookup occurs the file is still in existence but there is no > cached data, forcing the request to go down to the user-space > file-system. This would be used during remote rename. > > The second actually removes the dentry in the VFS in the kernel. This > would be used during remote deletion. Alright, seems there are as many different opinions on this as there are replies. So I tried to make sense of the code myself. I think Miklos and Amir are correct: the only difference between the functions is a call to fsnotify. At least as of kernel 4.8, both notify_delete and notify_inval_inode result in a call to fuse_reverse_inval_entry() in the kernel. And that function calls fuse_invalidate_attr (to invalidate the attributes of the parent) and fuse_invalidate_entry (which removes the dentry from the hash via d_invalidate *and* marks it as stale). The only difference is that when reverse_inval_entry is entered via notify_delete, it attempts to call d_delete (after the call to d_invalidate), which seems to have the effect of only calling fsnotify_nameremove(). John, are we missing something? 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