From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Subject: Re: [PATCH 17/18] gfs2: remove unnecessary dentry_unhash on rmdir/rename_dir Date: Tue, 10 May 2011 09:45:15 +0100 Message-ID: <1305017115.2839.2.camel@menhir> References: <1305002616-16782-1-git-send-email-sage@newdream.net> <1305002616-16782-18-git-send-email-sage@newdream.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: viro@ZenIV.linux.org.uk, hch@lst.de, linux-fsdevel@vger.kernel.org, cluster-devel@redhat.com To: Sage Weil Return-path: Received: from mx1.redhat.com ([209.132.183.28]:16642 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932623Ab1EJIn1 (ORCPT ); Tue, 10 May 2011 04:43:27 -0400 In-Reply-To: <1305002616-16782-18-git-send-email-sage@newdream.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi, On Mon, 2011-05-09 at 21:43 -0700, Sage Weil wrote: > Gfs2 has no issues with lingering references to unlinked directory > inodes. > > CC: Steven Whitehouse > CC: cluster-devel@redhat.com > Signed-off-by: Sage Weil > --- > fs/gfs2/ops_inode.c | 5 ----- > 1 files changed, 0 insertions(+), 5 deletions(-) > > diff --git a/fs/gfs2/ops_inode.c b/fs/gfs2/ops_inode.c > index 4bf862c..09e436a 100644 > --- a/fs/gfs2/ops_inode.c > +++ b/fs/gfs2/ops_inode.c > @@ -572,8 +572,6 @@ static int gfs2_rmdir(struct inode *dir, struct dentry *dentry) > struct gfs2_holder ri_gh; > int error; > > - dentry_unhash(dentry); > - > error = gfs2_rindex_hold(sdp, &ri_gh); > if (error) > return error; > @@ -743,9 +741,6 @@ static int gfs2_rename(struct inode *odir, struct dentry *odentry, > int error; > > if (ndentry->d_inode) { > - if (S_ISDIR(ndentry->d_inode->i_mode)) > - dentry_unhash(ndentry); > - > nip = GFS2_I(ndentry->d_inode); > if (ip == nip) > return 0; I recently posted some patches to this area of code, and I was intending to push them into my GFS2 -nmw tree today, so I wonder if you could simplify this by not adding the dentry_unhash into gfs2 in the first place, which would then ensure no conflicts between the two patch sets? Steve.