Re: [PATCH] allow tune2fs to set/clear resize_inode

[Theodore Tso <tytso@mit.edu>]

On Tue, Nov 06, 2007 at 09:12:55AM +0800, Andreas Dilger wrote:
> I don't know that it is so easy to enable RESIZE_INODE on an existing
> filesystem as just setting the feature flag and running e2fsck?  The
> reserved group descriptor blocks will potentially conflict with the
> bitmaps and inode tables.

Yes, it isn't so easy, and yup, it will potentially conflict with the
bitmap and inode tables --- and this is something which e2fsck does
*not* handle well.  

> What is needed is an ext2prepare-like step that involves resize2fs code
> to move the file/dir blocks and then the move inode table, as if the
> filesystem were going to be resized to the new maximum resize limit,
> and then create the resize inode but do not actually add new blocks/groups
> at the end of the filesystem.

Yeah, the plan was to eventually add ext2prepare-like code into
tune2fs, using the undo I/O manager for safety.  But that's been
relatively low priority.

BTW, I've gotten ~2 bug reports from Debian users claiming that
ext2prepare had trashed their filesystem.  I don't have any clean
evidence about whether it was a userspace error or some kind of bug in
ext2prepare, possibly conflicting with some new ext3 feature that
we've since added that ext2prepare doesn't properly account for
(extended attributes, maybe?).  

I have not had time to look into it, but thought has crossed my mind
that a quick hack would be to splice the undo manager into
ext2prepare, have it run e2fsck, and if it fails, do a rollback,
create an e2image file, and then instruct the user to send in a bug
report.  :-)

							- Ted