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?
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
> 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...
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs
On Thu, Mar 11, 2010 at 10:38:25AM -0600, Eric Sandeen wrote:
> 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.
> 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.
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
[email protected] wrote:
> On Thu, Mar 11, 2010 at 10:38:25AM -0600, Eric Sandeen wrote:
>> 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.
>
>> 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.
>
> 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.
Just to be clear, I -certainly- don't mean to say that if Red Hat doesn't
want it, upstream shouldn't work on it... but I have these concerns with
my upstream hat on, as much as with my red one.
> 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.
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?
Just something to think about.
> 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.
Agreed, but I'd say we got lucky this time in that respect ;)
Thanks,
-Eric
> Regards,
>
> - Ted
On Thu, Mar 11, 2010 at 06:27:48PM +0100, Jan Kara wrote:
> 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...
The number of places in userspace that try to automatically decide
whether to mount a particular filesystem as "ext2", "ext3", or "ext4",
is somewhat large. It's not just blkid (which is no longer under my
control); there are magic programs in various distributions
initramfs's, and I don't blame people who don't want to mess with that
that; at least for some distributions, it's a fragile PoS that the
less you have to mess with, the better. (Since any failures in the
initramfs image are effectively impossible to debug.)
So if some people want to be able to seemlessly start using ext4 and
not have to worry about doing a search through all of userspace and
their config files, and we get a bit more testing of ext4 in somewhat
"nonstandard" configurations, as far as I'm concerned it's all good.
I agree that most distributions are highly unlikely to ever want to
turn on this CONFIG option; it's really more for the Linux From
Scratch or maybe Gentoo users.
- Ted
On Thu, Mar 11, 2010 at 01:54:42PM -0600, Eric Sandeen wrote:
> 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
[email protected] wrote:
> On Thu, Mar 11, 2010 at 01:54:42PM -0600, Eric Sandeen wrote:
>> 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
I'd be happy with that. It always bites me when I forget ;)
Do we still need auto_da_alloc as a disable-able option?
-Eric