linux-ext4 - what exactly is CONFIG_EXT4_USE_FOR

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-next>] [day] [month] [year] [list]

Date:	Thu, 11 Mar 2010 10:38:25 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	ext4 development <linux-ext4@...r.kernel.org>
Subject: what exactly is CONFIG_EXT4_USE_FOR_EXT23 for?

commit 24b584240a0006ea7436cd35f5e8983eb76f1e6f
Author: Theodore Ts'o <tytso@....edu>
Date:   Mon Dec 7 14:08:51 2009 -0500

    ext4: Use ext4 file system driver for ext2/ext3 file system mounts

    Add a new config option, CONFIG_EXT4_USE_FOR_EXT23 which if enabled,
    will cause ext4 to be used for either ext2 or ext3 file system mounts
    when ext2 or ext3 is not enabled in the configuration.

    This allows minimalist kernel fanatics to drop to file system drivers
    from their compiled kernel with out losing functionality.

    Signed-off-by: "Theodore Ts'o" <tytso@....edu>

So now we have this thing, and people are using it, and running into trouble:

http://bugzilla.kernel.org/show_bug.cgi?id=15420
Bug 15420 -  EXT4_USE_FOR_EXT23 causes wrong free space calculation on ext2 and ext3

and now we propose turning off delalloc if we mount ext3 as ext4; however, migrated
ext3->ext4 filesystems, which initially may have no difference other than a
superblock feature flag, will not get this behavior, I guess.

Jan suggests that we not surprise users by having delalloc enabled when ext3
is mounted with the ext4 driver.  However there are other behavior differences
as well, mballoc behavior comes to mind at least.  What about the 32000 subdir
limit?  If we go back to ext3 is it ok with the subsecond timestamps and
creation time etc?  Maybe so... have we tested any of this?

At what point do we include the phase of the moon as worth considering when 
describing ext4.ko behavior?

I guess my point here is I think we have completely crossed the line of a
coherent story of what ext4 is and how it's supported and tested; things are
feeling so tuning-knob-option-happy and full of caveats that our matrix looks
infinite from where I stand.

This option won't be enabled on fedora or rhel, (and I don't mean to single out 
this particular commit, it just got me started on this train of thought)
but I just wanted to air a general concern that ext4 not try to be 10,000 different 
things to all people, and focus on something testable, documentable, and supportable.

For myself and the distros I work on, I strongly prefer to limit things to:

a) filesystems mkfs'd and mounted as ext4
b) ext3 filesystems migrated according to a very specific set of steps

All these other sub-cases and what-ifs and except-unless behaviors really
muddy the water, IMHO.

</vent>  ;)

Thanks,
-Eric
--
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