From: Steven Whitehouse <swhiteho@redhat.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org,
Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH 5/6] clean up OCFS2 nlink handling
Date: Fri, 11 Aug 2006 10:38:31 +0100 [thread overview]
Message-ID: <1155289111.3384.441.camel@quoit.chygwyn.com> (raw)
In-Reply-To: <1155236818.19249.265.camel@localhost.localdomain>
Hi,
On Thu, 2006-08-10 at 12:06 -0700, Dave Hansen wrote:
> On Thu, 2006-08-10 at 09:07 +0100, Steven Whitehouse wrote:
> > On Wed, 2006-08-09 at 12:15 -0700, Dave Hansen wrote:
> > > On Wed, 2006-08-09 at 18:12 +0100, Christoph Hellwig wrote:
> > [snip]
> > > > did you look whether gfs2 in -mm needs something similar?
> > >
> > > It doesn't appear to. It doesn't manipulate i_nlink in the same, direct
> > > manner.
> >
> > I think it will need something similar. I suspect the required changes
> > will all be confined to routines in inode.c. If the link count is
> > changed by (a) remote node(s), then gfs2_inode_attr_in() might change
> > the link count. Also gfs2_change_nlink() is the other place to look. I
> > think everywhere else is ok,
>
> Well, I think this is all that it needs. I'm trying to decide if we
> need a set_nlink() function for users like this, but I'm not sure there
> are enough of them.
>
I suspect that something is required for gfs2_inode_attr_in() as well.
Here is the scenario... suppose there are two nodes A and B. On node A a
file is opened, on node B the same file is then unlinked such that its
link count hits zero. If node A then does something to the file (read or
write, it doesn't matter) then it will reread the attributes off disk
via gfs2_inode_attr_in() and discover that the link count is then zero.
We don't play any games in that once the link count has hit zero, thats
it, it will never increment above zero again. The node which actually
deals with the deallocation and clean up is the one that performs the
final close (iput). This is dealt with using the iopen lock to ensure
that we are certain of which node is the last to close the file. The
iopen lock is held in a shared state by all nodes having the file open.
On gfs2_delete_inode we attempt to upgrade the iopen lock to exclusive,
if this succeeds we then presume that no other node has the file open
and proceed with deallocation, as per a normal local filesystem.
So if I've understood what you are doing correctly, the adjustment
you've made below needs to be copied into gfs2_inode_attr_in() as well,
Steve.
> ---
>
> lxc-dave/fs/gfs2/inode.c | 3 +++
> 2 files changed, 3 insertions(+)
>
> diff -puN fs/gfs2/inode.c~gfs fs/gfs2/inode.c
> --- lxc/fs/gfs2/inode.c~gfs 2006-08-10 09:52:33.000000000 -0700
> +++ lxc-dave/fs/gfs2/inode.c 2006-08-10 12:05:06.000000000 -0700
> @@ -332,6 +332,9 @@ int gfs2_change_nlink(struct gfs2_inode
> ip->i_di.di_ctime = get_seconds();
> ip->i_inode.i_nlink = nlink;
>
> + if (!nlink)
> + ip->i_inode.i_state |= I_AWAITING_FINAL_IPUT;
> +
> gfs2_trans_add_bh(ip->i_gl, dibh, 1);
> gfs2_dinode_out(&ip->i_di, dibh->b_data);
> brelse(dibh);
>
>
> -- Dave
>
next prev parent reply other threads:[~2006-08-11 9:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-09 16:57 [PATCH 0/6] read-only bind mount prep work Dave Hansen
2006-08-09 16:57 ` [PATCH 1/6] prepare for write access checks: collapse if() Dave Hansen
2006-08-09 17:09 ` Christoph Hellwig
2006-08-09 17:18 ` Dave Hansen
2006-08-09 16:57 ` [PATCH 2/6] r/o bind mount prepwork: move open_namei()'s vfs_create() Dave Hansen
2006-08-09 17:09 ` Christoph Hellwig
2006-08-09 16:57 ` [PATCH 4/6] r/o bind mount prepwork: inc_nlink() helper Dave Hansen
2006-08-09 17:11 ` Christoph Hellwig
2006-08-09 16:57 ` [PATCH 3/6] unlink: monitor i_nlink Dave Hansen
2006-08-09 17:11 ` Christoph Hellwig
2006-08-09 17:17 ` Dave Hansen
2006-08-09 18:27 ` Andrew Morton
2006-08-12 14:15 ` Arnd Bergmann
2006-08-09 16:57 ` [PATCH 5/6] clean up OCFS2 nlink handling Dave Hansen
2006-08-09 17:12 ` Christoph Hellwig
2006-08-09 19:15 ` Dave Hansen
2006-08-10 8:07 ` Steven Whitehouse
2006-08-10 19:06 ` Dave Hansen
2006-08-11 9:38 ` Steven Whitehouse [this message]
2006-08-09 16:57 ` [PATCH 6/6] monitor zeroing of i_nlink Dave Hansen
2006-08-09 17:14 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1155289111.3384.441.camel@quoit.chygwyn.com \
--to=swhiteho@redhat.com \
--cc=akpm@osdl.org \
--cc=haveblue@us.ibm.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox