On So, 28.06.20 11:15, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) 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. systemd is not in the business of being a RAID manager, i.e. it has no understanding of a policy regarding how long to wait for how many devices before continuing in degraded mode. This is something the btrfs people have to come up with. At the moment we support an absolute minimum mechanism: we wait until all members of the btrfs RAID array are there, and the last device popping up of it then marks the btrfs fs to be ready to mount. That's all. That's what 64-btrfs.rules does, nothing more. Now, if you put a time-out on waiting for a file system (which is the default, though most installers turn it off when LUKS is involved, since required interactivity — i.e. entering the pw — can take any time in the world) then you will enter emergency mode if RAID is not complete, and you can figure out yourself if you want to continue in degraded mode, systemd won't help you and this is not going to change. If there's demand for a RAID policy mgr for btrfs, it needs to be done by btrfs people, and maintained by them, I see no point in maintaining anything but the most minimum support for btrfs activation in systemd. Lennart -- Lennart Poettering, Berlin _______________________________________________ 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
