[systemd-devel] shutdown umount order
Lennart Poettering
lennart at poettering.net
Mon Jan 7 06:41:25 PST 2013
On Sat, 05.01.13 02:22, Ilya Basin (basinilya at 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.
More information about the systemd-devel
mailing list