[ext2resize] Re: Odd stride issues

[Robert W. <rj...@du...>]

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

Attached is the output of two different mke2fs's on a small loopback
file.  One has the resize inode.  The other doesn't.  Neither had a
stride specified.  As you can see, the one that has the resize inode has
a different layout depending on whether there is supposed to be a backup
super block there or not, which is what is causing ext2online to get
upset.

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

Sure.  I'm going to trace through this today, so I'll let you know as
soon as I get some interesting results.  I don't know if I made it clear
yesterday, but this message never occurs when the stride is specified
_AND_ set insanely huge.  Looking at the mke2fs code, when the stride is
set to an insanely huge value, it should result in the start_blk for
each block group being set back to the first block in the block group. 
Hmm.

Regards,
 Robert.