| |||||||||||||
Ext4 data corruption troubleExt4 data corruption troublePosted Oct 25, 2012 11:16 UTC (Thu) by nix (subscriber, #2304)In reply to: Ext4 data corruption trouble by tomegun Parent article: Ext4 data corruption trouble [Updated]
Sure! But... what if you have a mount point causing stalls (perhaps relating to an inaccessible NFS server), with mounted local filesystems buried beyond it? If you do a umount, rather than a umount -l, your shutdown will lock up forever as soon as it hits that mount point.
Worse yet, what if you have processes in other PID namespaces, holding open filesystems in other filesystem namespaces? The initramfs can't even see them! *No* umount loop can fix that. I hate adding new syscalls, but I really do think we need a new 'unmount the world' syscall which can cross such boundaries :(
(Log in to post comments)
Ext4 data corruption trouble Posted Oct 25, 2012 12:50 UTC (Thu) by rleigh (subscriber, #14622) [Link]
It would be nice for such a system call to also work for selected mount namespaces, so that you can be sure everything is consistent after the last process in the namespace exits. (I assume once the namespace no longer has any users, the mounts are automatically umounted?)
Ext4 data corruption trouble Posted Oct 25, 2012 13:31 UTC (Thu) by nix (subscriber, #2304) [Link]
I think that's so, yes: that's how MNT_DETACH and MNT_EXPIRE are implemented (and, thus, umount -l).
|
|||||||||||||