Ext4 data corruption trouble

Posted Oct 24, 2012 22:00 UTC (Wed) by tomegun (guest, #56697)
In reply to: Ext4 data corruption trouble by nix
Parent article: Ext4 data corruption trouble [Updated]

If you use "the right" initramfs (e.g. dracut or Arch's mkinitramfs) with systemd, it might work better.

In that case systemd will jump back to the initramfs on shutdown, and the initramfs will then try to kill/unmount whatever processe/mounts remains in the rootfs.

Ext4 data corruption trouble

Posted Oct 25, 2012 11:16 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

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 :(

Ext4 data corruption trouble

Posted Oct 25, 2012 12:50 UTC (Thu) by rleigh (guest, #14622) [Link] (1 responses)

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).