On Wed, Feb 15, 2023 at 07:39:28PM -0800, Russ Allbery wrote:
> It had never occurred to me before that the version of the system on which
> I run mke2fs would matter as long as I didn't pick a newer file system
> type (ext5 or something). Now I know! Until today, I had no idea ext4
> even *had* "incompat" features or that mke2fs could make file systems that
> grub couldn't understand.
While ext2 pioneered the whole concept of "compat", "rocompat" and
"incompat" features, these days pretty much all modern Linux file
systems have this. As I mentioned earlier, xfs is enabling their
incompat "bigtime" feature for the first time in Bookworm.
File sysems have been evolving pretty much continuously since ext2 was
first released 30 years ago. Poeple may have gotten lucky that grub
only (mostly) cares about incompat and rocompat features, but things
like adding extended attributes, 64-bit block number support,
post-2038 timestamps, etc., all require changes to the on-disk format.
And may of these updates did not happen at a extN to extN+1 boundary.
As far as the kernel is concerned, ext2/ext3/ext4 is really more about
allowing multiple implementations co-existing. These days, "ext3"
file systems are handled by the code in fs/ext4/*.c, and the only
reason why we've kept fs/ext2/*.c is to provide sample file system
code more than anything else. Many distributions (including Debian)
use fs/ext4 to support the ext2 file systems, via kernel config
CONFIG_EXT4_USE_FOR_EXT2.
As I mentioned, for the most part file system developers have tended
to care much more about kernel and file system utility
back-compatibility. This is probably because we have our own ways of
controlling these issues using controls such as /etc/mke2fs.conf, but
also because we tend to worry much more about data disks than
installers. And if much fewer Debian users tend to boot using say,
xfs or f2fs, perhaps people have just not noticed and complained.
Moving forward, certainly I and other fs developers will be spending
more time worrying about grub2 handling various file system features.
For example, grub2 doesn't understand the ext4 "casefold" feature, and
someday someone might want to make a Debian derivitive where users'
home directories work like MacOS and Windows...
Documenting this in ext4(5) is a bit challenging, because (a) not all
users use the grub2 bootloader, and (b) that means we'd have to
continuously update ext4(5) as grub2 changes. But certainly we could
make a generic warning in ext4(5).
It might be that a Wiki is the best place for this. The Arch and
Gentoo wikis have some of this already, since Arch and Gentoo users
tend to believe in enabling all file system developers (whether it is
good for them or not). That's great for me in terms of beta testers
for features that I don't think is 100% ready for prime time, but
that's another reason why using a newer mkfs is a bad idea.
For example, the inline_data feature is *not* ready for prime time,
but it's been getting better, and someday we might enable it by
default in Debian N+x. It'll *mostly* work so long as you don't
stress-test creating writing, truncating, etc., small files, but if
vmdb2 enables inline_data for Bookworm even though the Bookworm
e2fsprogs doesn't enable inline_data by default (but some future
Debian N+x does enable it by default), some users' lives might get
*exciting*, since the Bookworm will probably will be on the 6.1 LTS
kernel.
- Ted
