mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Whitehouse <swhiteho@redhat.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Srinivasa Ds <srinivasa@in.ibm.com>,
	linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>,
	fabbione@ubuntu.com, bunk@stusta.de, aarora@linux.vnet.ibm.com,
	aarora@in.ibm.com
Subject: Re: [RFC][PATCH] Mount problem with the GFS2 code
Date: Thu, 30 Nov 2006 09:05:38 +0000	[thread overview]
Message-ID: <1164877538.3752.93.camel@quoit.chygwyn.com> (raw)
In-Reply-To: <20061130002934.829334a6.akpm@osdl.org>

Hi,

On Thu, 2006-11-30 at 00:29 -0800, Andrew Morton wrote:
> On Thu, 30 Nov 2006 15:04:55 +0530
> Srinivasa Ds <srinivasa@in.ibm.com> wrote:
> 
> > ==========================================================================
> > On debugging further we found that problem is while reading the super 
> > block(gfs2_read_super) and comparing the magic number in it.
> > When I  replace the submit_bio() call(present in gfs2_read_super) with 
> > the sb_getblk() and ll_rw_block(), mount operation succeded.
> 
> umm, why on earth does gfs2_read_super() go direct-to-BIO?
> 
We want to make 100% certain that we are not reading cached data in
either of the two cases in which we read the sb. It is read from disk
exactly twice on each mount of a GFS2 filesystem and is never touched
again while the fs is mounted. GFS2 never writes the sb, it is created
by mkfs and never changes.

The reason its read twice, is that the first time its read to get the
details of the locking protocol, the second time its called under a lock
in order to discover the location of various bits of metadata on the
disk.

> Switching to sb_getblk()+ll_rw_blk() sounds like a preferable fix.
> 
> Even better would be switching to a bare sb_bread().   If sb->s_blocksize
> isn't set up by then then either set it up or, if you must, use __bread().
> 
I'm not convinced yet... I'd be happy to take the patch as posted
assuming that the reason you are suggesting using sb_bread() or similar
is that you expected us to want to cache the sb. Was there another
reason for not using the bio routines?

Steve.



  reply	other threads:[~2006-11-30  9:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-30  9:34 Srinivasa Ds
2006-11-30  8:29 ` Andrew Morton
2006-11-30  9:05   ` Steven Whitehouse [this message]
2006-11-30  9:12     ` Andrew Morton
2006-11-30  9:30       ` Steven Whitehouse

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=1164877538.3752.93.camel@quoit.chygwyn.com \
    --to=swhiteho@redhat.com \
    --cc=aarora@in.ibm.com \
    --cc=aarora@linux.vnet.ibm.com \
    --cc=akpm@osdl.org \
    --cc=bunk@stusta.de \
    --cc=fabbione@ubuntu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=srinivasa@in.ibm.com \
    --cc=torvalds@osdl.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

all inboxes | Powered by JetHome®