[ext2resize] Re: Odd stride issues

[Andreas D. <ad...@cl...>]

[ note - I've CC'd the discussion to ext...@li... ]

On Sep 11, 2002  15:08 -0700, Robert Walsh wrote:
> If I create a filesystem without specifying a stride value, ext2online
> prints out warning messages:
> 
>  # mke2fs -j -R resize=19398656 /dev/sdc1 38797312
>  # mount /dev/sdc1 /t
>  # ext2online /t 19398656
>  ext2online v1.1.18 - 2001/03/18 for EXT2FS 0.5b
>  This is odd, the RAID stride is not constant at -1540!
>  This is odd, the RAID stride is negative (-1540)!
>  Using a RAID stride value of 0
> 
> Sometimes the stride number is not negative, but it almost always
> complains that it's not constant.

Can you look at the output from dumpe2fs to see when/where/why the block
and inode bitmaps come after the inode table (which in my books means
that a stride was used).  If not, then the "stride detection" code in
ext2online is broken for some reason...  It's not supposed to be critical
stuff, mind you, just trying to keep the new groups layed out as the
original creator intended.

> The resize almost never completes when it prints the above errors and
> almost always completes when it doesn't.  It gives this kernel message
> when it fails:
> 
> verify_group_input: Block bitmap (11240450) in GDT table
> (11239424-11240451)

That would be badness then.  Probably the user-space calcs are bad, and
not the check here, so the kernel is getting bad data.  If you could
trace through where these calculations are going wrong, I can tell you
what the intention of them is, if you have questions.

> Another thing: the parser that picks apart the -R option arbitrarily
> breaks when certain paramater sequences are given to it.  For example,
> before I modified it, it was choking on -R resize=19398656,stride=8 but
> working OK when you switched the order.  The working order broke when I
> changed to a different stride value, etc.  It seems like strtoul is not
> behaving itself and crapping on the end_ptr parameter inconsistently.  I
> believe it's a piece of inlined code, so maybe it's doing the wrong
> thing.

That parameter doesn't actually work yet, for a reason that currently
escapes me.  Something about us needing data (like blocksize, or blocks
per group, or something) that we don't have until inside libext2 where
the filesystem is being created...  We need to go from "-R resize=foo"
to a number of group descriptor blocks that are passed in the
superblock to the libext2 create routines.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/