Re: [ext2resize] Re: Odd stride issues

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

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

I don't think this will have an effect.  If you specify "-O resize_inode"
to mke2fs, it will pick a default of 1024x the specified filesystem size, 
and the libext2 code will create a resize inode with enough blocks,
after it has determined all of the needed parameters (ext2fs_initialize()
maybe).  I _think_ there is a calculation in that same function which
determines the inode table offset, based on the group blocks + 3 (super,
block, inode bitmaps).  It probably needs s_reserved_gdt_blocks added in
there and we will be happy.

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