* Theodore Ts'o > Support for the on-line resizing inode has been integrated into > e2fsck, mke2fs, and resize2fs (so that the off-line resizer knows > about the resize inode, and can optimize its resizing activities when > shrinking or growing a filesystem with a on-line resize inode).
Ohh, I wasn't aware of the last part there about resize2fs. Cool! > So if you create a filesystem from scratch, you can indeed create it > with with the resize inode. However, ext2prepare is so scary that I > refuse to simply suck it into e2fsprogs until I rework it > significantly (and this may require a rewrite from scratch). > Basically, I'm not willing to maintain it and vouch for it not > trashing user's filesystems in its current state. I know that mke2fs supports creating the resize inode - orelse I wouldn't have submitted #346580. :-) And I didn't mean to suggest that you should just copy ext2prepare verbatim into e2fsprogs without any quality checking! I had my suspicions that its code quality were way below par... Thanks for confirming that. > So unfortunately, there is no way to safely add an on-line resize > inode to an existing filesystem using e2fsprogs. This is definitely > an undesirable state of affairs, but it's a matter of me finding time > to fix up ext2preprae. Yep. And even though it /might/ be safe to use ext2online followed by e2fsck I wouldn't even trust my web browser cache to that process... So effectively there is currently NO way to safely add a resize inode to a filesystem. Which indeed is an undesireable state of affairs, as you so eloquently put it. Especially considering that most distributions (including Debian, as far as I know) create filesystems lacking the resize inode during their installation process. > You mean the tool to trigger the on-line resizing functionality in the > kernel? That's probably easier for me to move into e2fsprogs. Yes. However, I think it does more than just tell the kernel to start a resize process. If I have understood correctly the kernel itself is only able to resize filesystems to sizes that are multiples of a certain size (128MB for filesystems with a 4k block size, if <http://ext2resize.sf.net/online.html> are to be believed). The rest is done by the tool itself somehow... But don't take my word for it. :-) From my sparse testing the ext2online tool appears to work correctly. I haven't been able to make it corrupt any filesystem yet, anyway. However due to the state of the ext2resize package as a whole it doesn't look like it's ever going to make it any stable release of Debian, and probably not any other distro either. That's why it would be very nice to see that functionality replicated in e2fsprogs as well as ext2prepare-equivalent functionality, so that e2fsprogs can do everything the ext2resize tools could, effectively obsoleting it. However, even though I would trust an ext2online-ish tool developed by you much more than the one that's currently available, it would be possible to have a complete resizing suite in stable if either ext2prepare is fixed (I seriously doubt that will happen) or equivalent functionality is added to e2fsprogs, and the RC bugs of ext2resize are dealt with by simply removing the ext2resize (#285257) and ext2online (#348778) tools from the package. That's why this whishlist bug is primarily about implementing ext2prepare-like functionality - if that happens I will try to convince ext2resize's maintainer to "fix" his RC bugs that way - unless you add ext2online-like functionality as well, of course, in which case I couldn't care less about ext2resize. :-) Kind regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
