linux-ext4 - Re: [PATCH 3/3] e2fsprogs: Support for large inode migration.

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]

Date:	Thu, 26 Jul 2007 12:13:25 -0400
From:	Theodore Tso <tytso@....edu>
To:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 3/3] e2fsprogs: Support for large inode migration.

On Thu, Jul 26, 2007 at 05:15:30PM +0530, Aneesh Kumar K.V wrote:
> >Let me guess, you're testing with a filesystem with two block groups,
> >right?  And to date you've tested *only* by doubling the size of the
> >inode.
> 
> I tested this with multiple ( 1 and 7 ) groups. But yes all the
> testing was to change inode size from 128 to 256.

Your patch comments stated "As a part of increasing the inode size we
throw away the free inodes in the last block group."  This is *only*
true if the filesystem has two (and exactly two) block groups.  Hence
my guess that only tested on filesystems with two block groups.

If you tested with larger numbers of block groups, the filesystem must
have been mostly empty, or at least not a large number of directories,
or else you would have noticed that most of the time that your
algorithm wouldn't work.

> I guess Undo I/O manager can go in because I have been using it for
> the ext3 -> ext4 inode migration testing and for testing the above patch.

Well, I really want a valid use case for undo code, and right now the
above patch is IMHO not suitable for merging into mainline, given all
of the problems that it has.

> Why would one need to recover on mkfs. He can very well run mkfs again 
> right ?

The idea is if there is a valid ext2/3 filesystem, and someone runs
mkfs on that filesystem, that it creates an undo file so that if
someone fumble-figured the arguments to mkfs, it becomes possible to
undo it.

In the ideal case the undo file would be copied into blocks that were
not in use by the original file, and placed into the new filesystem,
so that, so that it would be possible to undo the mkfs without needing
a separate file.  But I think it would be acceptable to say, "previous
ext3 filesystem detected; to undo the mke2fs operation, please run the
command 'undoe2fs /var/tmp/XXXX /dev/sdYY' in order to recover".

> >Presumably the only thing we can do is to abort the run and then back
> >out the chnages using what was written out to the undo file.
> >
> 
> I had a FIXME!! in the code which stated it would be nice to use the
> conf file But right now the conffile is e2fsck specific

Actually, e2fsck and mke2fs have their own config files.  An open
issue is whether we should have a separate tune2fs config file, or a
more general e2fsprogs.conf file.  Or we could have tune2fs use the
mke2fs.conf file, which is a bit of UI surprise; OTOH, tune2fs and
mke2fs do share code already, so it does make sense from a progamming
point of view.  I do consider it a UI botch, though.

Another possibility is to merge e2fsck.conf and mke2fs.conf into a
single config file, with symlinks for backwards compatibility.  My
current thinking is to just to add a new e2fsprogs.conf file, and let
tune2fs use it.  But I'm certainly willing to hear arguments for other
ways of handling this.

Or maybe we could just simply add a default of /var/lib/e2fsprogs, and
just leave it be for now.

					- 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