On Sat, Jun 27, 2020 at 9:40 PM Tom Seewald <tseewald@xxxxxxxxx> wrote: > > > On Sat, Jun 27, 2020 at 7:32 PM Garry T. Williams <gtwilliams(a)gmail.com> wrote: > > > > > > Just a PSA: btrfs raid1 does not have a concept of automatic degraded > > mount in the face of a device failure. By default systemd will not > > even attempt to mount it if devices are missing. > > Is this hopefully seen by upstream as a bug that will be fixed? This removes the system availability benefits of raid, and I've never heard of another system that would behave like this, whether that's zfs, md, or hardware raid. I'm not sure where it is in the priority list. If you're doing a preemptive replace, there's no degraded state. Even if there's a crash during this replace, all devices are present, so it'll boot normally. The difficulty is if a drive has died, and there's a reboot before a replace has started. There might be a way to add a delay timeout to the systemd-udev rule to make sure a degraded mount is intentional, rather than due to some transient delay of one drive - something like this already exists with mdadm assembly in dracut, maybe 90 seconds? Anyway, that doesn't eliminate all the risk but it might be OK for some setups. Other work is needed in this area, for example installations on UEFI don't automatically create two EFI system partitions, so there aren't two bootloaders or NVRAM entries. There's a hack/workaround that upstream linux-raid@ doesn't like, where md raid1 is used for the ESP, etc. /boot/efi should just go away entirely. There is no good reason for bootloader volumes being persistently mounted, they aren't user domain anyway, users shouldn't have to know about such things or repair them or sync them. I don't think it's in the initial mandate but something like this might be possible with the new bootupd project. https://github.com/coreos/bootupd -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
