On Tue, Dec 19, 2017 at 7:46 AM, Tomasz Pala <gotar@xxxxxxxxxx> wrote: >Secondly - permanent failures are not handled "just > fine", as there is (1) no automatic mount as degraded, so the machine > won't reboot properly and (2) the r/w degraded mount is[*] one-timer. > Again, this should be: One of the reasons for problem 1 is problem 2. If we had automatic degraded mount, people would run into problem 2 and now they're stuck 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 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 or request notification for degradedness state, so desktop environments can inform the user of degradedness. 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. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
