what exactly is CONFIG_EXT4_USE_FOR_EXT23 for?

commit 24b584240a0006ea7436cd35f5e8983eb76f1e6f

Author: Theodore Ts'o <[email protected]>
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" <[email protected]>

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?

Yeah, this is a good point... Honestly, I don't quite understand what's
the problem with "minimalist kernel fanatics" going and mounting all the devices as ext4 (when they decided to compile kernel without ext2/3) - no need for special kernel option. It will probably need some tweaks in automounters but still...

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?

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.

Quoted 4 lines · Eric Sandeen

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?

The block allocator behaviour does change, but not in user-visible fashion. And there have been times in the past when we've messed with the ext3's allocation algorithms (Mingming's reservation windows being the most recent example), and that falls pretty squarely into a non-user visible (aside from a performance increase) change.

Breaking the subdir limit requires a feature flag (DIR_NLINK) so it's not something that would be seen when mounting an ext3-compatible file system using ext4.

The reason why disabling delalloc by default when using ext4 to emulate ext3 may make sense is because it does have a potentially controversial impact with respect to applications which don't fsync() but which assumes that data blocks will magically be sync'ed to disk after five seconds. I disagree with that assumption, but the number of clueless application writers and users who have come to depend on it outnumber us by a fairly wide margin.

Quoted 15 lines

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

Quoted 2 lines

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

I think it's completely fair that Red Hat picks a subset of features to concentrate their testing and support on. And I am very sympathetic to the concerns of our exploding test matrix if we want to have complete coverage.

At the same time, there is some benefit in growing our community by support some other alternatives, which might not be that useful in the general case, or for an enterprise distro. So as we don't contaminate core code, and we can keep the code vaguely maintainable, a certain amount of flexibility and options is good.

I do think that it was highly reassuring to some key users of our userbase because we supported the use case of people who wanted to be able to use unmigrated ext2/3 file systems with the ability go back to ext2/3 afterwards. And the fact that in general e2fsck is more strict about file system consistency issues than the kernel, and e2fsck shows a clean file system after mounting an unmodified ext2/3 file system does reassure me. (And I will perform, from time to time, XFSQA tests using an ext2-compatible file system mounted using ext4). So that's why I was pretty comfortable with the CONFIG_EXT4_USE_FOR_EXT23 option.

And hey, users who used it quickly found a problem how we calculated indirect-mapped metablock reservations much more quickly than if we didn't have this option --- and this bug is one that would have eventually hit your "migrated ext3 file systems" case, except much more rarely, so the end result was a more robust file system.

So at least in this case, I think it was actually a net benefit.

Regards,

- Ted

As long as it doesn't contaminate the "core" then sure, but the more twisty paths we have, the less likely any of them will be maintainable. :)

I just think that before adding more knobs, we need to take a long hard look at what it does to the big picture. When documenting ext4 upstream, how many "if ... else if ... else if" clauses do we need?

Quoted 6 lines · Eric Sandeen

As long as it doesn't contaminate the "core" then sure, but the more twisty paths we have, the less likely any of them will be maintainable. :)

I just think that before adding more knobs, we need to take a long hard look at what it does to the big picture. When documenting ext4 upstream, how many "if ... else if ... else if" clauses do we need?

Fair enough.

I'm all for proposals to get rid of some knobs, too, if we don't think they serve a purpose. Recent examples that we've started deprecated include minixdf --- and I really wonder if we need t have explicit mount options to enable xattr and acl's. Anyone object if we just enable them all the time by default?

- Ted