[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1165223532.3752.561.camel@quoit.chygwyn.com>
Date: Mon, 04 Dec 2006 09:12:12 +0000
From: Steven Whitehouse <steve@...gwyn.com>
To: Russell Cattelan <cattelan@...hat.com>
Cc: cluster-devel@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [Cluster-devel] Re: [GFS2] Fix incorrect fs sync behaviour
[2/5]
Hi,
On Fri, 2006-12-01 at 11:57 -0600, Russell Cattelan wrote:
> On Mon, 2006-11-06 at 11:07 +0000, Steven Whitehouse wrote:
> > >From 4a221953ed121692aa25998451a57c7f4be8b4f6 Mon Sep 17 00:00:00 2001
> > From: Steven Whitehouse <swhiteho@...hat.com>
> > Date: Wed, 1 Nov 2006 09:57:57 -0500
> > Subject: [PATCH] [GFS2] Fix incorrect fs sync behaviour.
> >
> > This adds a sync_fs superblock operation for GFS2 and removes
> > the journal flush from write_super in favour of sync_fs where it
> > ought to be. This is more or less identical to the way in which ext3
> > does this.
> >
> > This bug was pointed out by Russell Cattelan <cattelan@...hat.com>
> >
> > Cc: Russell Cattelan <cattelan@...hat.com>
> > Signed-off-by: Steven Whitehouse <swhiteho@...hat.com>
> > ---
> > fs/gfs2/ops_super.c | 44 ++++++++++++++++++++++++++++----------------
> > 1 files changed, 28 insertions(+), 16 deletions(-)
> >
> > diff --git a/fs/gfs2/ops_super.c b/fs/gfs2/ops_super.c
> > index 06f06f7..b47d959 100644
> > --- a/fs/gfs2/ops_super.c
> > +++ b/fs/gfs2/ops_super.c
> > @@ -138,16 +138,27 @@ static void gfs2_put_super(struct super_
> > }
> >
> > /**
> > - * gfs2_write_super - disk commit all incore transactions
> > - * @sb: the filesystem
> > + * gfs2_write_super
> > + * @sb: the superblock
> > *
> > - * This function is called every time sync(2) is called.
> > - * After this exits, all dirty buffers are synced.
> > */
> >
> > static void gfs2_write_super(struct super_block *sb)
> > {
> > + sb->s_dirt = 0;
> This is a bit different than my original patch?
This was largely taken from the ext3 code as an example, rather than
your patch.
>
> Are you sure we don't need the s_lock here?
>
Yes. See linux-2.6/Documentation/filesystems/Locking:
locking rules:
All may block.
BKL s_lock s_umount
[snip]
write_super: no yes read
it is already held on entry to write_super,
Steve.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists