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 A7BF21580FD for ; Sun, 22 Dec 2024 20:05:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 10179E08AC; Sun, 22 Dec 2024 20:05:30 +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 B092BE08A4 for ; Sun, 22 Dec 2024 20:05:27 +0000 (UTC) Received: (qmail 78225 invoked by uid 3782); 22 Dec 2024 21:05:25 +0100 Received: from muc.de (p4fe15530.dip0.t-ipconnect.de [79.225.85.48]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 22 Dec 2024 21:05:25 +0100 Received: (qmail 4104 invoked by uid 1000); 22 Dec 2024 20:05:25 -0000 Date: Sun, 22 Dec 2024 20:05:25 +0000 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Fun with mdadm (Software RAID) Message-ID: References: <581a87bd-2578-47b2-8a68-2decc3db8991@youngman.org.uk> <2762363.mvXUDI8C0e@cube> 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: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Archives-Salt: 2fbff249-974a-448f-8f6a-b6ef1e116326 X-Archives-Hash: cb9566f7785657fd5c1a5d7bd0d01634 Hello, Wol. On Sun, Dec 22, 2024 at 16:53:17 +0000, Wols Lists wrote: > 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. This is the desirable state of affairs. > 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 all this 32 hex digit UUID stuff is a workaround for the unpredictability of server hardware. What seems to be missing is a way of associating a given disk socket on the motherboard with /dev/sda. Instead we have to put up with "content addressing". > 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! I think any system admins reading this would long for the predictability of "consumer hardware", having too often been confronted with indistinguishable 32 hex digit identifiers. I would imagine it quite likely that the said admins have written scripts to make this more manageable. > Cheers, > Wol -- Alan Mackenzie (Nuremberg, Germany).