public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Wols Lists <antlists@youngman.org.uk>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Fun with mdadm (Software RAID)
Date: Sun, 22 Dec 2024 16:53:17 +0000	[thread overview]
Message-ID: <eebd40de-d5fa-4d30-8170-d767a05c2d33@youngman.org.uk> (raw)
In-Reply-To: <2762363.mvXUDI8C0e@cube>

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


  reply	other threads:[~2024-12-22 16:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-20 10:47 [gentoo-user] Fun with mdadm (Software RAID) Alan Mackenzie
2024-12-20 14:50 ` karl
2024-12-20 15:28   ` Alan Mackenzie
2024-12-20 17:44     ` karl
2024-12-20 20:19       ` Alan Mackenzie
2024-12-20 20:38         ` Hoël Bézier
2024-12-20 20:53           ` Alan Mackenzie
2024-12-20 22:02         ` karl
2024-12-30  4:08           ` Frank Steinmetzger
2024-12-20 22:02         ` karl
2024-12-21 12:43           ` Alan Mackenzie
2024-12-21 16:36             ` Alan Mackenzie
2024-12-21 16:45               ` karl
2024-12-21 16:58                 ` Alan Mackenzie
2024-12-22 13:08                   ` Alan Mackenzie
2024-12-22 12:16             ` Wols Lists
2024-12-22 12:08         ` Wols Lists
2024-12-22 12:02       ` Wols Lists
2024-12-22 13:43         ` Alan Mackenzie
2024-12-22 15:29           ` Peter Humphrey
2024-12-22 16:53             ` Wols Lists [this message]
2024-12-22 20:05               ` Alan Mackenzie
2024-12-25 21:16                 ` Steven Lembark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eebd40de-d5fa-4d30-8170-d767a05c2d33@youngman.org.uk \
    --to=antlists@youngman.org.uk \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox