linux-ext4 - Re: [PATCH] allow tune2fs to set/clear resize

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071106185151.GA12857@thunk.org>
Date:	Tue, 6 Nov 2007 13:51:51 -0500
From:	Theodore Tso <tytso@....edu>
To:	Eric Sandeen <sandeen@...hat.com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] allow tune2fs to set/clear resize_inode

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html