Re: [RFC][PATCH] Mount problem with the GFS2 code

Re: [RFC][PATCH] Mount problem with the GFS2 code

[Andrew Morton]

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?

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().

Re: [RFC][PATCH] Mount problem with the GFS2 code

[Steven Whitehouse]

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.

Re: [RFC][PATCH] Mount problem with the GFS2 code

[Andrew Morton]

On Thu, 30 Nov 2006 09:05:38 +0000
Steven Whitehouse <swhiteho@redhat.com> wrote:

> Was there another
> reason for not using the bio routines?

Just that it's a layering violation.

Could I commend to you the use of code comments for this sort of thing?

Re: [RFC][PATCH] Mount problem with the GFS2 code

[Steven Whitehouse]

Hi,

On Thu, 2006-11-30 at 01:12 -0800, Andrew Morton wrote:
> On Thu, 30 Nov 2006 09:05:38 +0000
> Steven Whitehouse <swhiteho@redhat.com> wrote:
> 
> > Was there another
> > reason for not using the bio routines?
> 
> Just that it's a layering violation.
> 
> Could I commend to you the use of code comments for this sort of thing?

Ok. I'll take the patch, and then add a suitable comment. I'll make a
note to change it to use the bh based functions at some stage in the
future,

Steve.

[RFC][PATCH] Mount problem with the GFS2 code

[Srinivasa Ds]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

Hi all
  While mounting the gfs2 filesystem,our test team had a problem and we 
got this error message.
=======================================================

GFS2: fsid=: Trying to join cluster "lock_nolock", "dasde1"
GFS2: fsid=dasde1.0: Joined cluster. Now mounting FS...
GFS2: not a GFS2 filesystem
GFS2: fsid=dasde1.0: can't read superblock: -22

==========================================================================
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.
On further analysis we found that before calling submit_bio(), 
bio->bi_sector was set to "sector" variable. This "sector" variable has 
the same value of bh->b_blocknr(block number). Hence there is a need to 
multiply this valuwith (blocksize >> 9)(9 because,sector size 
2^9,samething happens in ll_rw_block also, before calling submit_bio()).
So I have developed the patch which solves this problem. Please let me 
know your comments.
================================================================

Signed-off-by: Srinivasa DS <srinivasa@in.ibm.com>



[-- Attachment #2: gfs2.fix --]
[-- Type: text/plain, Size: 488 bytes --]

 super.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.19-rc6/fs/gfs2/super.c
===================================================================
--- linux-2.6.19-rc6.orig/fs/gfs2/super.c
+++ linux-2.6.19-rc6/fs/gfs2/super.c
@@ -199,7 +199,7 @@ struct page *gfs2_read_super(struct supe
 		return NULL;
 	}
 
-	bio->bi_sector = sector;
+	bio->bi_sector = sector * (sb->s_blocksize >> 9);
 	bio->bi_bdev = sb->s_bdev;
 	bio_add_page(bio, page, PAGE_SIZE, 0);