On Sun, Jun 28, 2020 at 11:15:01AM -0600, Chris Murphy wrote: > 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. Nb. this is how mdadm works - assembly starts a timer from udev rule. If the timer passes but not all devices are present, the array is started in degraded mode: https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/udev-md-raid-assembly.rules https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/systemd This is a bit hackish, as there is a hardcoded amount of seconds system will wait for all devices. Also, this scheme was created by mdadm maintainer. He can be trusted to be knowledgable enough about md. Btrfs assembly rules, on the other hand, are maintained in systemd. Systemd developers are not btrfs experts, so they are cautious and quite conservative. degraded-assembly-after-timeout should be shipped in btrfs-progs, and maintained by people who are btrfs experts. -- Tomasz Torcz 72->| 80->| tomek@xxxxxxxxxxxxxx 72->| 80->| _______________________________________________ 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
