Re: [ext2resize] Re: Odd stride issues

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

On Sep 12, 2002  15:41 -0700, Robert Walsh wrote:
> > 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.
> 
> Is this the one?
> 
>         /*
>          * Overhead is the number of bookkeeping blocks per group.  It
>          * includes the superblock backup, the group descriptor
>          * backups, the inode bitmap, the block bitmap, and the inode
>          * table.
>          */
>         overhead = (int) (2 + fs->inode_blocks_per_group);
> 
>         if (ext2fs_bg_has_super(fs, fs->group_desc_count - 1))
>                 overhead += 1 + fs->desc_blocks + super->s_reserved_gdt_blocks;

Nope, this value is only used to determine whether the last group is
too small to be included in the filesystem.  The real culprit appears
to be in ext2fs_allocate_group_table(), where it is calculating the
start_blk value.  It isn't including the reserved GDT blocks there,
just before it allocates the inode table.

Since I changed the above "overhead" calculation to not require the
reserved blocks for non-backup-holding groups, the code in
ext2fs_allocate_group_table() probably needs to special-case the
situation where (the corrected) start_blk + fs->inode_blocks_per_group
is more than last_blk, and move the inode table down until it fits.

Or, we could revert the "overhead" calculation changes (and put the
comment that "being clever is tricky" back in) like you suggested, so
that it always includes the backup and reserved GDT.  The only problem is
as follows: say you are reserving for a huge filesystem, and you want
1024 reserved group blocks (the maximum, for a 4kB block filesystem,
which would give you an upper filesystem size of 16TB[*])

If it turns out that the last group in your filesystem does not contain
backups (probably true), but it is smaller than ~4MB you will lose that
space until you resize slightly larger than 4MB, even though you don't
need to store a group descriptor table into that group ever.  Maybe it's
not a big deal (4MB is in the noise these days ;-), and you are already
"wasting" at least 8MB of space for the initial reserved GDT blocks in
groups 0 and 1.  It's not like you don't get that space back later when
you resize, and presumably you are going to resize if you are reserving
blocks.

Cheers, Andreas
[*] coincidentally also the current maximum 4kB filesystem size because
    of the 2^32 block limit).
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/