Re: [ext2resize] Re: Odd stride issues

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

On Thu, 2002-09-12 at 12:24, Andreas Dilger wrote:
> On Sep 12, 2002  11:49 -0700, Robert Walsh wrote:
> > 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.
> 
> This may have something to do with how the libext2 code does block
> allocation.  I would think that it puts all of the inode tables at
> the same offsets, but it might be missing a "reserved_gdt" count in
> its initial calculations.

Well, there is this in the code that parses the resize parameter:

     /* XXX param->s_res_gdt_blocks = resize - existing
     cur_groups = (resize - sb->s_first_data_block +
                   EXT2_BLOCKS_PER_GROUP(super) - 1) /bpg;
     cur_gdb = (cur_groups + gdpb - 1) / gdpb;
     */

I assume this was an attempt to set this up, right?  But the problem is
figuring out what "existing" is.  I also assume this was the missing
information you mentioned in your email yesterday:

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

Anyway, I'm going to see if I can get the above bit working and if that
has an effect on the inode table offsets.

Regards,
 Robert.