On Tue, Dec 19, 2017 at 11:47 PM, Austin S. Hemmelgarn <ahferro...@gmail.com> wrote: > On 2017-12-19 15:41, Tomasz Pala 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 >> >> 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. > > Or maybe systemd can quit trying to treat BTRFS like a volume manager (which > it isn't) and just try to mount the requested filesystem with the requested > options?
You can't mount filesystem until sufficient number of devices are present and not waiting (at least attempting to wait) for them opens you to races on startup. So far systemd position was - it is up to filesystem to give it something to wait on. And while apparently everyone agrees that current "btrfs device ready" does not fit the bill, this is the only thing we have. This integration issue was so far silently ignored both by btrfs and systemd developers. -- 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
