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 D835915802C for ; Fri, 20 Dec 2024 15:28:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 94C22E08BB; Fri, 20 Dec 2024 15:28:34 +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 6E466E07EF for ; Fri, 20 Dec 2024 15:28:32 +0000 (UTC) Received: (qmail 47215 invoked by uid 3782); 20 Dec 2024 16:28:30 +0100 Received: from muc.de (pd953a3d6.dip0.t-ipconnect.de [217.83.163.214]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 20 Dec 2024 16:28:30 +0100 Received: (qmail 8450 invoked by uid 1000); 20 Dec 2024 15:28:29 -0000 Date: Fri, 20 Dec 2024 15:28:29 +0000 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Fun with mdadm (Software RAID) Message-ID: References: <20241220145053.B361C85A435A@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: <20241220145053.B361C85A435A@turkos.aspodata.se> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Archives-Salt: 8da757f9-2abd-4d21-b50d-cbac44d4d9dc X-Archives-Hash: e6950fd4d1b4ea2583482c73879f96c8 Hello, Karl. On Fri, Dec 20, 2024 at 15:50:53 +0100, karl@aspodata.se wrote: > Alan Mackenzie: > ... > > The cause was me booting up the machine with a rescue disk. This > > assembled my RAID partitions /dev/md127 and /dev/md126 reversed, but > > also wrote those wrong identifiers, 126 and 127, into the "preferred > > minor" field of the partitions' super blocks. In essence, they got > > swapped. > ... > > Just for the record, all my RAID arrays have metadata version 0.90, the > > (old fashioned) one that allows auto-assembly by the kernel without the > > need of an initramfs. > > The moral of the story: if your system uses software RAID, be careful > > indeed before you boot up with a rescue disk. > So, why don't you simple add "root=902 md=2,/dev/sda2,/dev/sdb2" or similar to > your boot loader kernel command line ? 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. > /// > And... what is the need for dynamic minors now when dev_t is 32bits: Dynamic minors? I don't think I follow you, here. > $ grep dev_t /Net/git/linux-stable/include/linux/types.h > typedef u32 __kernel_dev_t; > typedef __kernel_dev_t dev_t; > $ > and we have 20 bits minors: > $ grep -A1 MINORBITS /Net/git/linux-stable/include/linux/kdev_t.h > #define MINORBITS 20 > #define MINORMASK ((1U << MINORBITS) - 1) > #define MAJOR(dev) ((unsigned int) ((dev) >> MINORBITS)) > #define MINOR(dev) ((unsigned int) ((dev) & MINORMASK)) > #define MKDEV(ma,mi) (((ma) << MINORBITS) | (mi)) > Regards, > /Karl Hammar -- Alan Mackenzie (Nuremberg, Germany).