public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Whitehouse <steve@chygwyn.com>
To: Russell Cattelan <cattelan@redhat.com>
Cc: cluster-devel@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [Cluster-devel] Re: [GFS2] Fix incorrect fs sync behaviour [2/5]
Date: Mon, 04 Dec 2006 09:12:12 +0000	[thread overview]
Message-ID: <1165223532.3752.561.camel@quoit.chygwyn.com> (raw)
In-Reply-To: <1164995853.1194.42.camel@xenon.msp.redhat.com>

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@redhat.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@redhat.com>
> > 
> > Cc: Russell Cattelan <cattelan@redhat.com>
> > Signed-off-by: Steven Whitehouse <swhiteho@redhat.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.



      reply	other threads:[~2006-12-04  9:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-06 11:07 [GFS2] Fix incorrect fs sync behaviour [2/5] Steven Whitehouse
2006-12-01 17:57 ` Russell Cattelan
2006-12-04  9:12   ` Steven Whitehouse [this message]

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=1165223532.3752.561.camel@quoit.chygwyn.com \
    --to=steve@chygwyn.com \
    --cc=cattelan@redhat.com \
    --cc=cluster-devel@redhat.com \
    --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