From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: [PATCH 09/11] exportfs: update Exporting documentation Date: Fri, 6 Jun 2014 17:23:32 -0400 Message-ID: <20140606212332.GF29883@pad.redhat.com> References: <1401916863-7916-1-git-send-email-bfields@redhat.com> <1401916863-7916-10-git-send-email-bfields@redhat.com> <538F957D.5010405@itwm.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Al Viro , Christoph Hellwig , linux-fsdevel@vger.kernel.org To: Bernd Schubert Return-path: Received: from mx1.redhat.com ([209.132.183.28]:31113 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751635AbaFFVX6 (ORCPT ); Fri, 6 Jun 2014 17:23:58 -0400 Content-Disposition: inline In-Reply-To: <538F957D.5010405@itwm.fraunhofer.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Jun 04, 2014 at 11:54:05PM +0200, Bernd Schubert wrote: > On 06/04/2014 11:21 PM, J. Bruce Fields wrote: > >From: "J. Bruce Fields" > > > >Minor documentation updates: > > - refer to d_obtain_alias rather than d_alloc_anon > > - explain when to use d_splice_alias and when > > d_materialise_unique. > > - cut some details of d_splice_alias/d_materialise_unique > > implementation. > > > >Signed-off-by: J. Bruce Fields > >--- > > Documentation/filesystems/nfs/Exporting | 38 +++++++++++++++++++------------ > > 1 file changed, 23 insertions(+), 15 deletions(-) > > > >diff --git a/Documentation/filesystems/nfs/Exporting b/Documentation/filesystems/nfs/Exporting > >index e543b1a..9b7de5b 100644 > >--- a/Documentation/filesystems/nfs/Exporting > >+++ b/Documentation/filesystems/nfs/Exporting > >@@ -66,23 +66,31 @@ b/ A per-superblock list "s_anon" of dentries which are the roots of > > > > c/ Helper routines to allocate anonymous dentries, and to help attach > > loose directory dentries at lookup time. They are: > >- d_alloc_anon(inode) will return a dentry for the given inode. > >+ d_obtain_alias(inode) will return a dentry for the given inode. > > If the inode already has a dentry, one of those is returned. > > If it doesn't, a new anonymous (IS_ROOT and > > DCACHE_DISCONNECTED) dentry is allocated and attached. > > In the case of a directory, care is taken that only one dentry > > can ever be attached. > >- d_splice_alias(inode, dentry) will make sure that there is a > >- dentry with the same name and parent as the given dentry, and > >- which refers to the given inode. > >- If the inode is a directory and already has a dentry, then that > >- dentry is d_moved over the given dentry. > >- If the passed dentry gets attached, care is taken that this is > >- mutually exclusive to a d_alloc_anon operation. > >- If the passed dentry is used, NULL is returned, else the used > >- dentry is returned. This corresponds to the calling pattern of > >- ->lookup. > >- > >+ d_splice_alias(inode, dentry) or d_materialise_unique(dentry, inode) > >+ will introduce a new dentry into the tree; either the passed-in > >+ dentry or a preexisting alias for the given inode (such as an > >+ anonymous one created by d_obtain_alias), if appropriate. The two > >+ functions differ in their handling of directories with preexisting > >+ aliases: > >+ d_splice_alias will use any existing IS_ROOT dentry, but it will > >+ return -EIO rather than try to move a dentry with a different > >+ parent. This is appropriate for local filesystems, which > >+ should never see such an alias unless the filesystem is > >+ corrupted somehow (for example, if two on-disk directory > >+ entries refer to the same directory.) > >+ d_obtain_alias will attempt to move any dentry. This is > >+ appropriate for distributed filesystems, where finding a > >+ directory other than where we last cached it may be a normal > >+ consequence of concurrent operations on other hosts. > >+ Both functions return NULL when the passed-in dentry is used, > >+ following the calling convention of ->lookup. > >+ > > Hmm, is this really supposed to be in nfs/Exporting? Wouldn't be a new > chapter in vfs.txt or a new file dache.c more appropriate? I was looking in > the past for their documentation, but then thought it does not exist - one > needs to use these even without nfs exports. Yes, nfs for example uses d_materialise_unique despite not itself being exportable. I'm not opposed to finding a better home for this. --b.