On 03/20/2014 01:21 AM, Chris Murphy wrote:
On Mar 19, 2014, at 7:51 PM, Adam Williamson <awill...@redhat.com> wrote:
On Wed, 2014-03-19 at 15:57 -0700, Andrew Lutomirski wrote:
More complex than trying to mirror a FAT ESP partition across multiple
boot disks, keeping it properly synchronized, because RAID isn't
supported?
You can in theory just have a bunch of RAID-1 (mirrored) ESPs, because
of how RAID-1 works; each individual member can also be mounted as if it
was just a plain old partition, which is how the firmware will mount it.
This shouldn't be done. It's a source of corruption to treat an md raid1 device
as a plain volume, rather than as a degraded md device. If the plain partition
volume is modified, its mdadm metadata won't be updated, so when the array is
finally assembled, mdadm has no idea member devices are not sync'd, and also
has no way to resolve the ambiguity.
Right, but UEFI doesn't write to it----it just uses them to read the
boot content. It would be better if UEFI could read software raid1 even
if it was degraded due to disk failures, but apparently it can't, so
Adam's scheme is the only possibility.
I agree with you that nothing else but UEFI should mount those devices
as individual plain volumes, of course.
Because of this, at least one raid stack kernel maintainer wants to do away
with the use of mdadm metadata v 1.0 by anaconda. It's v1.0 metadata that
permits this plain old partition treatment as a side effect.
It is a darn useful side effect. How else can you implement redundant
boot that is transparently updated? I could (and did) try
multiple /boot partitions on separate drives by copying the partition
content after updates, but it was fragile and I was never confident that
it would work when I needed it. Adam's raid1 /boot just seems more
reliable, especially if it became a designed feature.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
