Hello, Karl.
On Fri, Dec 20, 2024 at 23:02:58 +0100, k...@aspodata.se wrote:
> Alan Mackenzie:
> > On Fri, Dec 20, 2024 at 18:44:53 +0100, k...@aspodata.se wrote:
> ...
> > > Please tell if you make booting with metadata 1.2 work.
> > > I havn't tested that.
> > I've just tried it, with metadata 1.2, and it doesn't work. I got error
> > messages at boot up to the effect that the component partitions were
> > lacking valid version 0.0 super blocks.
> > People without initramfs appear not to be in the sights of the
> > maintainers of this software. They could so easily have made the
> > assembly of metadata 1.2 components on the kernel command line work.
> > :-(
> ...
> The cmd line handling and auto mounting seems to be handled in files
> like (depending of kernel version I guess):
> drivers/md/md-autodetect.c
> init/do_mounts_md.c
> you can find the correct file with
> find <kernel top dir> -type f -name \*.c | xargs grep MD_AUTODETECT
The pertinent functions are mainly in drivers/md/md-autodetect.c and
md.c (same directory).
It seems that nowhere does this code try the different metadata formats
in turn, using the first valid one that it finds. Instead, it expects
the metadata format to be passed in as an argument to whatever needs it.
For the md kernel parameter to be able to load metadata versions
1.[012], the parameter definition would have to be enhanced, somehow.
Something like:
md=124,1.2,/dev/nvme0n1p6,/dev/nvme1n1p6
^^^^
, where the extra bit is optional. This enhancement would not be
difficult. The trouble is more political. I think this code is
maintained by RedHat. RedHat's customers all use initramfs, so they
probably think everybody else should, too, hence would be unwilling to
enhance it for a small group of Gentooers.
> The problem might be that in format 1.2, the superblock is at 4K from
> start, could format 1.1 (where the superblock is at start) work ?
This doesn't seem to be the problem. The 0.90 superblock is right at
the end of the partition, for example. There are two functions in md.c,
super_90_load and super_1_load which read and verify the super block of
the given metadata type.
Despite the 0.90 format being "deprecated", it doesn't appear to be in
any danger. It was in a deprecated state in 2010, when I started using
RAID, and I think the maintainers realise that to phase 0.90 out would
cause a lot of pain and protest. The main limitation with 0.90 that I
can see is its restriction to 2^32 512-byte blocks per component device.
This is the 2 terabyte limitation, which isn't a problem for me at the
moment, but might be for other people with enormous drives.
Nevertheless, I might make the above enhancement, just because.
> Regards,
> /Karl Hammar
--
Alan Mackenzie (Nuremberg, Germany).
