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 156CD15802C for ; Fri, 20 Dec 2024 17:45:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E814AE0909; Fri, 20 Dec 2024 17:45:10 +0000 (UTC) Received: from turkos.aspodata.se (turkos.aspodata.se [185.140.117.226]) by pigeon.gentoo.org (Postfix) with ESMTP id 04AF1E08C2 for ; Fri, 20 Dec 2024 17:45:08 +0000 (UTC) Received: from turkos.aspodata.se (localhost.aspodata.se [127.0.0.1]) by turkos.aspodata.se (Postfix) with ESMTP id 6930C85A4352 for ; Fri, 20 Dec 2024 18:44:53 +0100 (CET) Received: by turkos.aspodata.se (Postfix, from userid 1000) id 4E33285A435A; Fri, 20 Dec 2024 18:44:53 +0100 (CET) X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7+dev X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: inbox From: karl@aspodata.se To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Fun with mdadm (Software RAID) In-reply-to: References: <20241220145053.B361C85A435A@turkos.aspodata.se> Comments: In-reply-to Alan Mackenzie message dated "Fri, 20 Dec 2024 15:28:29 +0000." 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 Message-Id: <20241220174453.4E33285A435A@turkos.aspodata.se> Date: Fri, 20 Dec 2024 18:44:53 +0100 (CET) X-Virus-Scanned: ClamAV using ClamSMTP X-Archives-Salt: 68b3cd9b-1e0c-4524-93c7-af21435921bf X-Archives-Hash: 697631c62c8607b05afe001ac7167bf4 Alan Mackenzie: > On Fri, Dec 20, 2024 at 15:50:53 +0100, karl@aspodata.se wrote: ... > Because I didn't know about it. I found out about it this morning, and > immediately tested it by setting up an > "md=126,/dev/nvme0n1p4,/dev/nvme1n1p4" on the kernel command line, using > the rescue disk to make the "preferred minor"s wrong, and testing it. > It worked! > > If I understand things correctly, with this mechanism one can have the > kernel assemble the RAID arrays at boot up time with a modern metadata, > but still without needing the initramfs. My arrays are still at > metadata 0.90. Please tell if you make booting with metadata 1.2 work. I havn't tested that. /// ... > > And... what is the need for dynamic minors now when dev_t is 32bits: > Dynamic minors? I don't think I follow you, here. If you partition the md device, the partitions will get a device with a dynamic minor. # mdadm -C /dev/md11 -n 1 -l 1 --force /dev/sdc2 # mdadm -C /dev/md10 -n 1 -l 1 -e 0 --force /dev/sdc1 ... create partitions # fdisk -l /dev/md10 ... Device Boot Start End Sectors Size Id Type /dev/md10p1 2048 22527 20480 10M 83 Linux /dev/md10p2 22528 192383 169856 82.9M 83 Linux # fdisk -l /dev/md11 ... Device Boot Start End Sectors Size Id Type /dev/md11p1 2048 206847 204800 100M 83 Linux /dev/md11p2 206848 1757183 1550336 757M 83 Linux # cat /sys/block/md10/md10p1/dev 259:0 # cat /sys/block/md10/md10p2/dev 259:1 # cat /sys/block/md11/md11p1/dev 259:2 # cat /sys/block/md11/md11p2/dev 259:3 $ grep -A2 '259 block' /Net/git/linux-stable/Documentation/admin-guide/devices.txt 259 block Block Extended Major Used dynamically to hold additional partition minor numbers and allow large numbers of partitions per device So, to boot to a md device partition (as /) might be a hit and miss unless you use some initramfs magic. Regards, /Karl Hammar