From: Alan Mackenzie <acm@muc.de>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Fun with mdadm (Software RAID)
Date: Sat, 21 Dec 2024 12:43:50 +0000 [thread overview]
Message-ID: <Z2a4Bvt0zX7vtSsL@MAC.fritz.box> (raw)
In-Reply-To: <20241220220258.7422F85A435A@turkos.aspodata.se>
Hello, Karl.
On Fri, Dec 20, 2024 at 23:02:58 +0100, karl@aspodata.se wrote:
> Alan Mackenzie:
> > On Fri, Dec 20, 2024 at 18:44:53 +0100, karl@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).
next prev parent reply other threads:[~2024-12-21 12:44 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 10:47 [gentoo-user] Fun with mdadm (Software RAID) Alan Mackenzie
2024-12-20 14:50 ` karl
2024-12-20 15:28 ` Alan Mackenzie
2024-12-20 17:44 ` karl
2024-12-20 20:19 ` Alan Mackenzie
2024-12-20 20:38 ` Hoël Bézier
2024-12-20 20:53 ` Alan Mackenzie
2024-12-20 22:02 ` karl
2024-12-30 4:08 ` Frank Steinmetzger
2024-12-20 22:02 ` karl
2024-12-21 12:43 ` Alan Mackenzie [this message]
2024-12-21 16:36 ` Alan Mackenzie
2024-12-21 16:45 ` karl
2024-12-21 16:58 ` Alan Mackenzie
2024-12-22 13:08 ` Alan Mackenzie
2024-12-22 12:16 ` Wols Lists
2024-12-22 12:08 ` Wols Lists
2024-12-22 12:02 ` Wols Lists
2024-12-22 13:43 ` Alan Mackenzie
2024-12-22 15:29 ` Peter Humphrey
2024-12-22 16:53 ` Wols Lists
2024-12-22 20:05 ` Alan Mackenzie
2024-12-25 21:16 ` Steven Lembark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z2a4Bvt0zX7vtSsL@MAC.fritz.box \
--to=acm@muc.de \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox