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 223511580FD for ; Sun, 22 Dec 2024 16:53:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 88C01E0885; Sun, 22 Dec 2024 16:53:20 +0000 (UTC) Received: from smtp.hosts.co.uk (smtp.hosts.co.uk [85.233.160.19]) (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 43494E07BA for ; Sun, 22 Dec 2024 16:53:19 +0000 (UTC) Received: from host81-152-157-204.range81-152.btcentralplus.com ([81.152.157.204] helo=[192.168.1.99]) by smtp.hosts.co.uk with esmtpa (Exim) (envelope-from ) id 1tPPCg-000000003Hp-5jcv for gentoo-user@lists.gentoo.org; Sun, 22 Dec 2024 16:53:19 +0000 Message-ID: Date: Sun, 22 Dec 2024 16:53:17 +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 User-Agent: Mozilla Thunderbird Subject: Re: [gentoo-user] Fun with mdadm (Software RAID) To: gentoo-user@lists.gentoo.org References: <581a87bd-2578-47b2-8a68-2decc3db8991@youngman.org.uk> <2762363.mvXUDI8C0e@cube> Content-Language: en-GB From: Wols Lists In-Reply-To: <2762363.mvXUDI8C0e@cube> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: b5b81c67-34b6-49a3-a2bf-25fff239c69c X-Archives-Hash: 48d9b218e2a13a4d6396121ef8f9c0bc On 22/12/2024 15:29, Peter Humphrey wrote: > 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. > I have no problem with you saying all this long guid crap makes stuff unreadable (and yes, I agree, unreadable and unmaintainable aren't that far different) BUT > surely outweighs the rare situation where the physical->logical assignment changes THAT DEPENDS ON YOUR HARDWARE! For normal consumer grade hardware, I agree. I've never known it change unless I've been mucking about with add-in SATA, PATA, whatever cards. BUT. Especially on big server-grade hardware, where there's lots of trip switches so stuff doesn't all power up in one huge spike (and I've worked with such), different parts of the system come up in a completely random order, and drives re-order themselves pretty much every single boot! So yes, with our consumer hardware I'd agree with you. But the people paying big bills for reliable top-range hardware would wonder what you're smoking! Cheers, Wol