[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-raid
Subject:    Re: How does one enable SCTERC on an NVMe drive (and other install questions)
From:       Chris Murphy <lists () colorremedies ! com>
Date:       2021-06-21 16:28:43
Message-ID: CAJCQCtQqtnh37hii+4Lb5gN33UWO+fWAcqBPyZJFM9rcp=ztEA () mail ! gmail ! com
[Download RAW message or body]

> 2) Topic two - RAID on /boot and /boot/efi
>
> It looks like RHEL 8 and clones don't support the installer building
> LVM on top of RAID as they used to.

I haven't tried it more recently in Fedora than a couple of years but
it was putting LVM on mdadm raid, so I'd expect it is too for RHEL 8.
I'm not sure how favoring LVM raid (LVM management and metadata, but
still uses the md kernel driver) is exposed in the installer GUI,
maybe it's just distinguished in kickstart?

>It also
> looks like maybe I cannot use the installer to set up RAID mirroring
> for /boot or /boot/efi.

I'm virtually certain it will create an ESP on mdadm metadata v 0.9
for /boot/efi, at least it used to. And it was discussed at the time
on this list as not a good idea because these are strictly mdadm
member drives, they aren't ESP's until the raid is assembled. So it
leads to discontinuity in the best case. You either have to lie with a
partition type claiming it's an ESP and yet it's really an mdadm
member; or you tell the truth by saying it's an mdadm member but then
possibly the firmware won't read from it because it has the wrong type
guid. And some firmware care about that and others don't.

Further, it's possible for the firmware to write to the ESP. Which in
this case means it modifies a member drive outside of kernel code and
now they mismatch. As long as no further writes happen to either drive
separate or via md, you could do a scrub repair and force the second
drive to match the first. So long as the firmware modified the first
drive, following scrub repair they'd both be properly in sync rather
than regressing to a prior state. But I think this is just damn sloppy
all the way around. The UEFI spec doesn't address syncing ESPs at all.
And so we're left with bad hacks like using software raid rather than
a proper utility that determines which drive has the most recent
changes and syncing them to the other(s), which could be as simple as
an rsync service unit for this task. Or possibly better would be for
the canonical contents of the distro directory that belongs on the
ESP, to actually be in /usr and sync from it as the primary source, to
all the ESPs. Neither /boot nor /boot/efi need to be persistently
mounted. It's just lack of resources and a good design that we keep
these things around all the time. They only need to be mounted when
they're updated. And they don't need to be mounted during boot because
they're used strictly by the firmware to achieve boot.

A better idea would be using x-systemd.automount and
x-systemd.idle-timeout so that it's mounted on demand and unmounted
when idle. Perhaps even better would be an exclusive owner that
handles such things. One idea proposed is bootupd,
https://github.com/coreos/bootupd and it could be enhanced to sync all
the ESPs as well, in multiple disk scenarios.




-- 
Chris Murphy
[prev in list] [next in list] [prev in thread] [next in thread]