On Sun, 2024-01-28 at 16:46 +0000, Andy Smith wrote:
> Hi,
> 
> On Sun, Jan 28, 2024 at 05:17:14PM +0100, hw wrote:
> > Ok if Andy and you are right, you could reasonably boot machines with
> > an UEFI BIOS when using mdadm RAID :)
> 
> I've been doing it for more than two decades, though not with UEFI.
> 
> > How is btrfs going to deal with this problem when using RAID?  Require
> > hardware RAID?
> > 
> > Having to add mdadm RAID to a setup that uses btrfs just to keep efi
> > partitions in sync would suck.
> 
> ESP have to be vfat so why are you bringing up btrfs?
> 
> If you want to use btrfs, use btrfs. UEFI firmware isn't going to
> care as long as your ESP is not inside that.

It's easy to boot from btrfs software RAID without further ado.  These
nasty and annoying UEFI partitions get in the way of that since they
are not kept in sync with each other when you have several without
further ado.

That easily leads to situations in which you can't boot after a disk
has failed despite you have RAID.  That is something that must not
happen; it defeats the RAID.  It's bad enough when you have access to
the machine and it's a total nightmare when not because you'll have to
somehow go there to fix this.  If the disk having the UEFI partition
has failed and there's no redundance that's at least sufficently in
sync, it's even worse.

Show me any installer for Linux distributions that handles this
sufficently without further ado.

When you don't use btrfs, you have either hardware RAID or
mdraid.  With harware RAID, the problem doesn't come up.  With mdadm
RAID, it isn't much better than with btrfs since without further ado,
you still don't have redundant UEFI partitions.  With btrfs and mdadm
RAID, it's basically worse because you have to deploy another variant
of software RAID in addition to the software built into btrfs.

So at least for boot disks, I'll go for hardware RAID whenever
possible, especially with btrfs, until this problem is fixed.  Or do
you have a better option?

Reply via email to