On 2016-07-06 14:48, Austin S. Hemmelgarn wrote: > On 2016-07-06 08:39, Andrei Borzenkov wrote: [....] >>>>> >>>>> To be entirely honest, if it were me, I'd want systemd to >>>>> fsck off. If the kernel mount(2) call succeeds, then the >>>>> filesystem was ready enough to mount, and if it doesn't, then >>>>> it wasn't, end of story. >>>> >>>> How should user space know when to try mount? What user space >>>> is supposed to do during boot if mount fails? Do you suggest >>>> >>>> while true; do mount /dev/foo && exit 0 done >>>> >>>> as part of startup sequence? And note that nowhere is systemd >>>> involved so far. >>> Nowhere there, except if you have a filesystem in fstab (or a >>> mount unit, which I hate for other reasons that I will not go >>> into right now), and you mount it and systemd thinks the device >>> isn't ready, it unmounts it _immediately_. In the case of boot, >>> it's because of systemd thinking the device isn't ready that you >>> can't mount degraded with a missing device. In the case of the >>> root filesystem at least, the initramfs is expected to handle >>> this, and most of them do poll in some way, or have other methods >>> of determining this. I occasionally have issues with it with >>> dracut without systemd, but that's due to a separate bug there >>> involving the device mapper. >>> >> >> How this systemd bashing answers my question - how user space knows >> when it can call mount at startup? > You mentioned that systemd wasn't involved, which is patently false > if it's being used as your init system, and I was admittedly mostly > responding to that. > > Now, to answer the primary question which I forgot to answer: > Userspace doesn't. Systemd doesn't either but assumes it does and > checks in a flawed way. Dracut's polling loop assumes it does but > sometimes fails in a different way. There is no way other than > calling mount right now to know for sure if the mount will succeed, > and that actually applies to a certain degree to any filesystem > (because any number of things that are outside of even the kernel's > control might happen while trying to mount the device.
I think that there is no a simple answer, and the answer may depend by context. In the past, I made a prototype of a mount helper for btrfs [1]; the aim was to: 1) get rid of the actual btrfs volume discovery (udev which trigger btrfs dev scan) which has a lot of strange condition (what happens when a device disappear ?) 2) create a place where we develop and define strategies to handle all (or most) of the case of [partial] failure of a [multi-device] btrfs filesystem By default, my mount.btrfs waited the needed devices for a filesystem, and mount in degraded mode if not all devices are appeared (depending by a switch); if a timeout is reached, and error is returned. It doesn't need any special udev rule, because it performs a discovery of the devices using libuuid. I think that mounting a filesystem and handling all the possibles case relaying of the udev and its syntax of the udev rules is more a problem than a solution. Adding that udev and the udev rules are developed in a different project, the difficulties increase. I think that BTRFS for its complexity and their peculiarities need a dedicated tool like a mount helper. My mount.btrfs is not able to solve all the problem, but might be a starts for handling the issues. BR G.Baroncelli [1] http://www.spinics.net/lists/linux-btrfs/msg28764.html -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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
