On Sun, Jun 28, 2020 at 12:39 AM Gabriel Ramirez <gabrielo@xxxxxxxxxx> wrote: > > On 6/27/20 11:09 PM, Chris Murphy wrote: > > On Sat, Jun 27, 2020 at 9:25 PM Gabriel Ramirez <gabrielo@xxxxxxxxxx> wrote: > >> On 6/27/20 9:06 PM, Chris Murphy 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. And it's not advised > >>> to use 'degraded' mount option in fstab. If you do need to mount > >>> degraded and later the missing device is found (?) you need to scrub > >>> to catch up the formerly missing device to the current state. > >>> > >> That seems a step back, > > Yes. You do gain self-healing and unambiguous scrubs, which apply only > > to the used portion of the drives. Three steps forward half step back? > > The priority would be to replace the failing/failed drive before a > > reboot. Yes, the use case where the drive dies on startup and > > unattended boot is needed is weaker. > > yeah, but coming from mdadm, I (will be)/(was) expecting the same or > better from a new filesystem, or documentation to resolve the situation > "shutdown, replace the disk, boot with another media etc..." > > because when the problem happens, googling sometimes fails too Some distros have /usr/lib/udev/rules.d/64-btrfs.rules and others don't. The behavior now, with that rule, udev waits for all btrfs devices to be present. And I think it's an indefinite wait. Is it a bug in the rule or is it a feature request? I don't know. But, I think at the least we'd want a timer to get to a dracut shell eventually. At that shell, you can e.g. mount -o degraded /dev/vda1 /sysroot exit And the startup will proceed normally the rest of the way and you can do a device replacement. A better udev rule might be one that waits for all devices, and then if there are still missing devices at say 90s is able to add 'degraded' to the initial mount attempt. That might mostly fix this. But I don't know if sd-udev can conditionally add (insert) mount options or if it could learn to do so. There is still some very small window of risk for a "split brain" type problem - if different devices get mount degraded on subsequent boots - but fixing/hardening against that requires kernel work. > at least one shutdown, start is needed (I have to open the computer > case, replace the hard disk) Yep, if you can't hotswap you do need one. > another reboot if after partition the drive the kernel complains about > "the current partition will be used until reboot" This shouldn't be necessary. The drive is not in use, so it's possible to apply the partition map, and the kernel should just update. If not then partprobe should do it. (Otherwise we'd have to reboot to do software installs, but we don't.) The limitation you're talking about is when repartitioning a drive that is in use already - and the old partition map is basically pinned in memory. And yes it's annoying. -- 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
