On Sat, Jan 27, 2018 at 15:22:38 +0000, Duncan wrote: >> manages to mount degraded btrfs without problems. They just don't try >> to outsmart the kernel. > > No kidding. > > All systemd has to do is leave the mount alone that the kernel has > already done, instead of insisting it knows what's going on better than > the kernel does, and immediately umounting it.
Tell me please, if you mount -o degraded btrfs - what would BTRFS_IOC_DEVICES_READY return? This is not "outsmarting" nor "knowing better", on the contrary, this is "FOLLOWING the kernel-returned data". The umounting case is simply a bug in btrfs.ko that should change to READY state *if* someone has tried and apparently succeeded mounting the not-ready volume. Otherwise - how should any system part behave when you detach some drive? Insist that "the kernel has already mounted it" and ignore kernel screaming "the device is (not yet there/gone)"? Just update the internal state after successful mount and this particular problem is gone. Unless there is some race condition and the state should be changed before the mount is announced to the userspace. -- Tomasz Pala <go...@pld-linux.org> -- 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
