[RFC] mke2fs with DIR_INDEX, RESIZE_INODE by default

[Stephen C. Tweedie]

HI,

On Sat, 2006-03-18 at 01:36 -0700, Andreas Dilger wrote:
> On Mar 17, 2006  17:26 -0500, Stephen C. Tweedie wrote:
> > I reckon they are safe enough for general use.  The only question mark
> > in my mind is over the change in behaviour for people who dual-boot or
> > swap data between newer and older distros.

> Well, both DIR_INDEX and RESIZE_INODE are COMPAT features, so if they
> are dual booting it shouldn't matter a bit.  FC3/FC4/RHEL4 have all
> been using RESIZE_INODE and it is very unlikely that it would introduce
> a bug.  The only thing I can imagine it causing problems with is if the
> e2fsprogs are old

That's exactly the case I'm thinking about, because we already see
complaints when newly-created filesystems cause older systems to fail to
boot --- e2fsck is run by default at boot time, and the default
behaviour (at least on RHEL/Fedora systems) is to drop to a
(password-protected) root prompt if fsck fails.

Note that the filesystem itself isn't the only reason for such boot
incompatibilities, either; the new MLS support in SELinux resulted in
file security contexts that older kernels can't decode, for example.
But I'd rather not make it worse.

> > One way around that that I've been wondering about would be to wait
> > until we have accumulated enough new features (extent maps/64-bit,
> > increase the default inode size etc.) and give the new feature set its
> > own explicit flag in mke2fs.
> 
> IMHO, "bundling" changes like this is counter productive.  We've had
> DIR_INDEX and RESIZE_INODE around for a long time already, and no point
> in lumping them in with code that is much less-well tested or supported
> (e.g. only 2.6.something kernels can even mount large inodes, which is
> a far cry from being read-write compatible).

Bundling them like that only makes sense when we've got to the point
where we've been able to merge a significant portion of the outstanding
INCOMPAT changes, agreed.  But if that's something that is achievable
reasonably soon, it would alleviate some of the pressure to change the
existing defaults.

> > It might be something we could call ext4 (ie. enable it if mke2fs is
> > called as "mke4fs"); we might just add a separate flag.  Whatever way
> > we chose, it would want to be something that would stand out as an
> > obviously non-backwards-compatible formatting option.
> 
> Interesting.  I thought we were against calling new feature sets ext(n+1),
> but that would be one way of doing it.

I'm against giving the kernel itself any knowledge about it, simply
because the existing feature sets are both sufficient and way more
flexible than any major revision number.

But from the user's perspective, once we've merged lots of incompat
changes and we think this new extended format is going to be stable for
a bit, a single flag to switch between old (maximal compatibility, no
new incompat features) and new (give me _all_ the new features, I know I
won't be using an old kernel) makes sense.

(Nearly all of the incompat features on the table do make sense to have
on by default.  Perhaps the most questionable one is larger inodes,
because of the tradeoff between functionality and capacity that that
implies; but if people really start relying on fast xattrs for samba4,
fine-grained timestamps etc., then even that one might make sense to be
on by default in the new feature-set.)

>   I'm also not sure why you would
> consider these two features as non-backwards-compatible format options?

It's purely because of the fsck boot-time compatibility concern; there
are absolutely no kernel compatibility problems I'm aware of.  And the
fsck-time bits can be avoided by removing the feature with tune2fs and
fsck, so it's not something I'm dead set against.

--Stephen