On Tue, Dec 19, 2017 at 1:41 PM, Tomasz Pala <go...@polanet.pl> wrote: > On Tue, Dec 19, 2017 at 12:35:20 -0700, Chris Murphy wrote: > >> with a read only file system. Another reason is the kernel code and >> udev rule for device "readiness" means the volume is not "ready" until >> all member devices are present. And while the volume is not "ready" >> systemd will not even attempt to mount. Solving this requires kernel >> and udev work, or possibly a helper, to wait an appropriate amount of > > Sth like this? I got such problem a few months ago, my solution was > accepted upstream: > https://github.com/systemd/systemd/commit/0e8856d25ab71764a279c2377ae593c0f2460d8f
I can't parse this commit. In particular I can't tell how long it waits, or what triggers the end to waiting. > > Rationale is in referred ticket, udev would not support any more btrfs > logic, so unless btrfs handles this itself on kernel level (daemon?), > that is all that can be done. > >> time. I also think it's a bad idea to implement automatic degraded >> mounts unless there's an API for user space to receive either a push > [...] >> There is no amount of documentation that makes up for these >> deficiencies enough to enable automatic degraded mounts by default. I >> would consider it a high order betrayal of user trust to do it. > > It doesn't have to be default, might be kernel compile-time knob, module > parameter or anything else to make the *R*aid work. OK but that's cart before the horse. The horse is proper recovery behavior once a delayed/missing drive appears, i.e. resync. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
