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 8FDAA1580FD for ; Sun, 22 Dec 2024 15:29:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 51F2EE08A8; Sun, 22 Dec 2024 15:29:20 +0000 (UTC) Received: from smarthost01c.sbp.mail.zen.net.uk (smarthost01c.sbp.mail.zen.net.uk [212.23.1.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3B112E08A0 for ; Sun, 22 Dec 2024 15:29:16 +0000 (UTC) Received: from [82.69.80.10] (helo=cube.localnet) by smarthost01c.sbp.mail.zen.net.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tPNsy-00BKjH-81 for gentoo-user@lists.gentoo.org; Sun, 22 Dec 2024 15:29:15 +0000 From: Peter Humphrey To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Fun with mdadm (Software RAID) Date: Sun, 22 Dec 2024 15:29:15 +0000 Message-ID: <2762363.mvXUDI8C0e@cube> In-Reply-To: References: <581a87bd-2578-47b2-8a68-2decc3db8991@youngman.org.uk> 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-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-Originating-smarthost01c-IP: [82.69.80.10] Feedback-ID: 82.69.80.10 X-Archives-Salt: 02a40897-b67f-4e18-a654-2e8786afaf8b X-Archives-Hash: 620c2bf60d5940bbebb9e120e696dd07 On Sunday 22 December 2024 13:43:08 GMT Alan Mackenzie wrote: > The trouble [is] that a kernel command line, or /etc/fstab, using lots > of these is not human readable, and hence is at the edge of > unmaintainability. This maintenance difficulty surely outweighs the > rare situation where the physical->logical assignment changes due to a > broken drive. That's what we've got rescue disks for. Hear, hear! I never could understand why everyone seems to want to jump onto that band-wagon. -- Regards, Peter.