Re: [ext2resize] Re: Odd stride issues

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

On Sep 13, 2002  10:49 -0700, Robert Walsh wrote:
> 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.

Good detective work.  Yes this is pretty much a summary of how things
happen on the ext2online side, based on how previous ext2 filesystems
were set up.  I think mke2fs is changing its behaviour slightly because
the reserved group descriptors are using up the space that it had saved
for the inode and block bitmaps, and the inode table is using them up
first.

> I guess that mke2fs is producing a legal layout, or is it?

Yes, it is totally legal, but just not very common.  However, I have
also learned recently that Ted's resize2fs tool also will move only
the bitmap blocks to after the inode table in the case it needs to
(offline) resize, while ext2resize will work to keep the old ordering.

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

Would this be for mke2fs or ext2online?  There might be two issues here.
1) mke2fs should try to keep the old "standard" layout as much as
   possible, because there are likely other tools which don't know
   anything about the fact that bitmaps can move (GNU parted might be
   one of those, because it uses a very old version of the ext2resize
   code).  This simply means making sure that the location of the inode
   table is offset enough to compensate for the reserved group
   descriptor blocks as we previously discussed.
2) ext2online shouldn't pass bad data (i.e. invalid bitmap locations) to
   the kernel.  Rather than picking the offset of the first group's inode
   table blindly, it should calculate itself what the offset needs to be

   sb + (2 bitmaps if not "striped") + in-use GDT blk + reserved GDT blk

   and use the maximum of that and the "current" inode table offset.
   I suppose it is almost doing this, but is getting confused because
   it assumes that if _any_ bitmaps are after the inode table, then it
   is "striped" and they will _all_ be after the inode table.  The bug
   happens when it can't find a regular striping pattern and uses
   stride = 0, it assumes that there is enough space before the inode
   table to hold the bitmaps.

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