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 - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
