Re: [ext2resize] Re: Odd stride issues

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

Hi,

It appears to me that what's happening is that ext2online is trying to
guess the stride value using the differences in the buffer bitmap
position in each block group.  This doesn't always give valid values,
but whether it does or it doesn't, it then tries to calculate the inode
table offset using its location in the first block group.  It then
creates a bunch of new groups to add using the inode table offset as
it's key.  It places the buffer bitmap and inode bitmap 2 blocks and 1
block before the inode table, respectively.  On blocks groups without a
super block backup, this is fine.  On those with a super block backup,
this causes the bitmaps to fall into the range of the reserved gdt
blocks because in those circumstances, the inode table generated by
mke2fs happens to fall before the bitmaps.

I guess that mke2fs is producing a legal layout, or is it?  It certainly
works for us, but it doesn't produce anything that looks like the layout
in your ols2002 paper.  One thought might be to rearrange the order in
which it allocates blocks, so that it always allocates the bitmaps first
and then the inode table. This will at least guarantee the ordering will
be correct.  I need to look at this a little more to be sure, though.

Regards,
 Robert.

--=20
Robert Walsh
Amalgamated Durables, Inc.  -  "We don't make the things you buy."
Email: rj...@du...