From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 64F3F1580FD for ; Sat, 21 Dec 2024 12:44:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1ECA4E0935; Sat, 21 Dec 2024 12:43:55 +0000 (UTC) Received: from mail.muc.de (mail.muc.de [193.149.48.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B5888E092E for ; Sat, 21 Dec 2024 12:43:53 +0000 (UTC) Received: (qmail 18213 invoked by uid 3782); 21 Dec 2024 13:43:51 +0100 Received: from muc.de (p4fe157a9.dip0.t-ipconnect.de [79.225.87.169]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 21 Dec 2024 13:43:50 +0100 Received: (qmail 3690 invoked by uid 1000); 21 Dec 2024 12:43:50 -0000 Date: Sat, 21 Dec 2024 12:43:50 +0000 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Fun with mdadm (Software RAID) Message-ID: References: <20241220145053.B361C85A435A@turkos.aspodata.se> <20241220174453.4E33285A435A@turkos.aspodata.se> <20241220220258.7422F85A435A@turkos.aspodata.se> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241220220258.7422F85A435A@turkos.aspodata.se> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Archives-Salt: bbce0b0e-2b6e-4f80-9151-ecbe8bbb52fa X-Archives-Hash: eae852fea04fc4d69a30e194cfc6c455 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 -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).