"Theodore Ts'o" <ty...@mit.edu> writes:
> As a long-term solution, one could image changing the various image
> creation tools to do something like "mfks.ext4 -T grub2_dumbdown
> /dev/XXX", and then have something like the following in
> /etc/mke2fs.conf:
> [fs_types]
> grub2_dumbdown = {
> features = ^metadata_csum_seed,^casefold
> }
This is considerably more specific than what I had in mind, but maybe I'm
misunderstanding the problem. Here's a slightly more fleshed out version
of what I was thinking:
mke2fs when run without any options has some default upstream-shipped set
of options that it enables (possibly via the upstream-shipped mke2fs.conf,
possibly in the binary, however it works). Those defaults presumably work
with the kernel and other system tools shipped at the time, due to the
normal compatibility due diligence that you'd naturally do while doing
file system development.
When you make changes to the *defaults* (not just the addition of any
options in general), this presumably is also aligned with what you think
is generally supported by other system tools at the time.
Each time you change the defaults in a way that could be
backward-incompatible, you could capture those new defaults in a
permanently-fixed label of, say, 20230616, which is the defaults on that
date. Probably in the default /etc/mke2fs.conf. I don't expect you to
care about what systems they work with, what distributions they work with,
or anything else other than the timeline of when you decided to change the
defaults, something you're presumably already doing as a maintainer. The
only additional work would be to update these labels with the settings
required to make mke2fs with its current defaults behave compatibly with
whatever the defaults had been at each of those captured points in time.
(And obviously eventually you could drop the really old ones if it made no
sense to keep supporting them, or have some single really-ancient fallback
for really old systems, etc.)
Then, image creators can look in /etc/mke2fs.conf for the timestamp that
most closely aligns with the target system they want to create and use
that group of settings. If that turns out to be inadequate, they can go
back to a previous date. Some work on their part is still required, but
from their perspective I think this would have the advantage of not having
to do research to reconstruct what all the options could be and how they
changed and which ones were potentially backward-incompatible, which are
all things you would generally already know and have in mind when you
changed the defaults and thus could capture for them.
That said, this is an architectural stab in the dark and I obviously don't
work on file system development, so maybe this isn't viable for some
reason that I'm not seeing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
