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 40DAF1580FD for ; Wed, 25 Dec 2024 21:17:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 28F42E07B2; Wed, 25 Dec 2024 21:16:57 +0000 (UTC) Received: from dizzy.wrkhors.com (static-72-65-219-98.eriepa.fios.verizon.net [72.65.219.98]) by pigeon.gentoo.org (Postfix) with ESMTP id D0E85E0784 for ; Wed, 25 Dec 2024 21:16:56 +0000 (UTC) Received: from wrkhors.com (localhost [127.0.0.1]) by dizzy.wrkhors.com (Postfix) with ESMTP id 0EC70C40B60B; Wed, 25 Dec 2024 16:16:56 -0500 (EST) Date: Wed, 25 Dec 2024 16:16:50 -0500 From: Steven Lembark To: gentoo-user@lists.gentoo.org Cc: lembark@wrkhors.com Subject: Re: [gentoo-user] Fun with mdadm (Software RAID) Message-ID: <20241225161650.5641a98a.lembark@wrkhors.com> In-Reply-To: References: <581a87bd-2578-47b2-8a68-2decc3db8991@youngman.org.uk> <2762363.mvXUDI8C0e@cube> Organization: Workhorse Computing X-Mailer: Claws Mail 4.3.0 (GTK 3.24.41; x86_64-pc-linux-gnu) X-Workhorse: Quite 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-Transfer-Encoding: 7bit X-Archives-Salt: dd190415-7987-4456-97ef-ea9de6985eff X-Archives-Hash: 35a9b5ef925a330736e6cc318d8b9d91 > 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. Simple fix: use LVM, let it deal with the UUID. At that point the PV's get UUID's, the VG's get UUID's, the LV's get UUID's and you never have to type or see or use them. Snippet from my /etc/fstab: /dev/vg00/root / xfs ... /dev/vg00/var /var xfs ... /dev/vg00/var-tmp /var/tmp xfs ... this is basically the same fstab on my server & notebook, hasn't changed in the transitions from ATA to SATA to SCSI to SAS to NVME. If you want mirroring then either create a mirror with mdadm and use it as a PV -- kenel will auto-start the mirror, vgscan will find it, and Viola!, it's up -- or use -m2 and mirror/stripe/ RAID5/whatever using lvcreate to spread the data across whatever you like. Here I have two nvme's (used to be scsi, then sas) which are mirrored for vg00 w/ the root, var, home filesystems another that's striped for /var/tmp and other scratch spaces. This gives an overview: https://speakerdeck.com/lembark/its-only-logical-lvm-for-linux -- Steven Lembark Workhorse Computing lembark@wrkhors.com +1 888 359 3508