On Sun, Oct 15, 2017 at 07:53:11PM +1100, Aleksa Sarai wrote:
> This is the bug that I talked to you about at LPC, related to devicemapper
> and it not being possible to issue DELETE and REMOVE operations on a
> devicemapper device that is still mounted in $some_namespace. [Before we go
> on, deferred removal and deletion can help here, but the deferral will never
> kick in until the reference goes away. On SUSE systems, deferred removal
> doesn't appear to work at all, but that's an issue for us to solve.]
Yeah, it's not really a bug, as much as (IMHO) a profound design
misfeature in the way mount namespaces work. And the fundamental
problem is that there are two distinct things that you might want to
do:
* In a container, "unmount" a file system is it no longer shows up in
your mount namespace.
* As a system administrator, make a mounted file system **go** **away**
because the device is about to disapear, either because:
* The iscsi/nbd device is gone or about to disappear (maybe the server is
about to shut down)
* The user wants to yank out the USB thumb drive
* The system is shutting down and for whatever reason the shutdown
sequence wants to remove the block device driver or otherwise shutdown
the UFS device on the Android system.
The last three examples are all real world examples where people have
complained to me about, and there have been some hacky things we've
done as a result.
We sort of have a hacky solution which works today, at least for f2fs,
ext4 and xfs file systems, which is you can use
{EXT4,F2FS}_FS_IOC_SHUTDOWN / XFS_IOC_GOINGDOWN ioctls to forcibly
shutdown the file system, and then recurse over all of /proc looking
for /proc/*/mounts files and seeing if the file system is mounted in
that namespace, and then either killing the pid or somehow entering
the namespace of that process and unmounting the file system. But
it's ugly and messy, and it's not at all intuitive, and so people keep
tripping against the problem.
What we really need is some kind of "global shutdown and unmount"
system call which safely and cleanly does this. Instead of relying on
the file system's brute force shutdown sequence, it would be better if
we implemented some kind of VFS-level revoke(2) functionality (ala the
*BSD revoke system call, which they've had for ages) on all file
descriptors opened on the file systems, and if any processes have a
CWD in the file system, it is replaced by an anonymous
invalid/"deleted" directory, followed by a syncfs() on the file
system, followed by a recursive search and removal of the file system
from all mount namespaces.
Obviously, this could only be used by someone with root privileges on
the "root" container.
- Ted
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
