On Sat, 05.01.13 02:22, Ilya Basin (basini...@gmail.com) wrote: > Hi list. > On shutdown I have > Buffer I/O error on device dm-... > because the truecrypt disk is unmounted later than the usb disk > containing the truecrypt image. > I think this happens, because > 1) systemd can't figure out the correct mount dependencies > 2) umount is called with the force flag
According tot he docs MNT_FORCE only has an effect on NFS, nothing else. Note that there are two phases of shutdown. a) the "clean" part, where the dependencies between the units is honoured, and which generally should suffice unmounting everything in the right order just fine. This code does not use MNT_FORCE, and can fail. b) the "last attempt" part, where dependencies are ignored, and where the code simply loops around umount() and a few other things until nothing can be unmounted/detached anymore, at which point it gives up. MNT_FORCE is used here. > --------- > There are workarounds specially for truecrypt, but why not solve the > problem entirely? > > 1) I think the mount dependencies can't be made 100% reliable. systemd > should use the combination of them and /proc/mounts, but only as a HINT > In my case /proc/mounts contains the right order. /proc/mounts doesn't really contain order information. > 2) Instead of force umount, systemd should first try to umount > everything gracefully, and if at least one mount point was unmounted > successfully, then retry. > Only if all mounts are busy, systemd should force umount the first > candidate and then repeat the graceful umount for others. Well, this assumes that MNT_FORCE was more than just a flag for NFS. How does truecrypt actually work? Does it expose its services through DM? If so, why does it let the block devices being detached without the FS on it being unmounted. To me this really sounds like a shortcoming of truecrypt that works very differently from loop or DM devices otherwise which you cannot detach as long as they are busy. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
