[ext2resize] Re: [Ext2-devel] Re: [patch] ext2fs_allocate_group_table cleanup

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

On Mar 17, 2006  13:00 -0500, Theodore Ts'o wrote:
> > As for ext2prepare, that is really just resize2fs that doesn't extend
> > the end of the filesystem, and creates/modifies the resize inode.  I
> > believe that e2fsck already handles the resize inode, so combining the
> > parts is all that's needed.
> 
> Not really.  You *can* do it using some somewhat obscure debugfs,
> followed by running e2fsck -f and answering yes to a whole bunch of
> scary questions, and in some cases it still might not work.  So we
> still need to enhance either resize2fs or write some new program if we
> want ext2prepare functionality.

Hmm, I'd think the basic functionality is mostly the same.  Use resize2fs
to move the inode bitmaps as if you were really going to resize the filesystem
and needed more group descriptor blocks.  Then "allocate" the reserved
group descriptor blocks to the resize inode.  What more is needed?  The
hard part of the operation (moving the itable, and file data blocks) is
already implemented in resize2fs.

> One thing I have thought about doing is simply enhacing
> /usr/src/linux/fs/ext3/resize.c to support metablock groups, and
> automatically switching to use meta blockgroups once there are no more
> reserved gdt blocks.  This means you no longer need ext2prepare, and
> aside from some conservative stick-in-the-mud types running RHEL 3 or
> other distro's with 2.4 kernels (heck, even Debian has finally gotten
> off of 2.4), all modern Linux systems will support the metablock group
> feature anyway.  This will allow us to do resizing without needing to
> use ext2prepare, or needing to reserve blocks at all.  

I believe that this is already implemented by Glauber de Oliveira Costa
<go...@br...> and posted to ext2-devel a month ago, see:
"[PATCH] Online Resizing - New attempt".  Sadly, I haven't yet looked
at it.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.