On Sat, Jan 27, 2018 at 6:26 AM, Adam Borowski <kilobyte@xxxxxxxxxx> wrote: > You're assuming that btrfs somehow knows this itself. Unlike the bogus > assumption systemd does that by counting devices you can know whether a > degraded or non-degraded mount is possible, it is in general not possible to > know whether a mount attempt will succeed without actually trying. That's right, although a small clarification is in order: systemd doesn't count devices itself. The Btrfs systemd udev rule defers to Btrfs kernel code by using BTRFS_IOC_DEVICES_READY. And it's totally binary. Either they are all ready, in which case it exits 0, and if they aren't all ready it exits 1. But yes, mounting whether degraded or not is sufficiently complicated that you just have to try it. I don't get the point of wanting to know whether it's possible without trying. Why would this information be useful if you were NOT going to mount it? > Ie, the thing systemd can safely do, is to stop trying to rule everything, > and refrain from telling the user whether he can mount something or not. Right. Open question is whether the timer and timeout can be implemented in the systemd world and I don't see why not, I certainly see it put various services on timers, some of which are indefinite, some are 1m30s and others are 3m. Pretty much every unit gets a descrete boot line with a green dot or red cylon eye as it waits. I don't see why at the very least we don't have that for Btrfs rootfs mounts because *that* alone would at least clue in a user why their startup is totally hung indefinitely. -- 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
