为什么文件系统已卸载但仍在使用？

Question

免责声明：我不能也不会在这个答案中解释为什么会触发内核部分故障。这看起来像是一个内核错误，可能是由 I/O 错误条件触发的。

长话短说

当新的挂载命名空间从原始挂载命名空间继承挂载的文件系统时，可能会出现文件系统仍在使用中的情况，但两者之间的传播设置并未使原始命名空间中的卸载将其传播到新命名空间中。该命令findmnt -A -o +PROPAGATION还在其输出中显示每个可见安装点的传播状态。

通常这不应该发生在系统环境，因为系统很早就进行/共享挂载（而不是内核默认的private），从而允许卸载在其共享组内传播。因此，我希望这种情况在非 systemd 环境中更容易发生，或者无论如何，如果工具--make-private在某些安装中明确使用的话。--make-private仍然有其用途，特别是对于虚拟伪文件系统。

防止这种情况发生的一种方法可能是，在创建新的挂载命名空间之前更改与共享的挂载点 mount --make-shared ...。

我做了一个实验来说明共享挂载与非共享挂载会发生什么情况。我试图确保实验在 systemd 或非 systemd 环境中都能同样工作。

实验

这可以像下面一样复制（某些值必须/dev/loop0进行调整）：

# truncate -s $((2**20)) /tmp/test.raw
# mkfs.ext4 -Elazy_itable_init=0,lazy_journal_init=0 -L test /tmp/test.raw
mke2fs 1.47.0 (5-Feb-2023)

Filesystem too small for a journal
Discarding device blocks: done                            
Creating filesystem with 1024 1k blocks and 128 inodes

Allocating group tables: done                            
Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done

# losetup -f --show /tmp/test.raw 
/dev/loop0
# mkdir -p /mnt/propagation/test

这将允许稍后更改实验的传播，而无需通过将目录转变为挂载点来更改整个系统：

# mount --bind /mnt/propagation /mnt/propagation

现在，不同的实验可能会产生不同的结果。

unshare(1)告诉：

unshare因为 util-linux 版本 2.27 会自动将传播设置到private新的挂载命名空间中，以确保新的命名空间确实是非共享的。可以使用选项禁用此功能--propagation unchanged。请注意，这private是内核默认值。

其他工具可能会这样做。在这里，我们将更改底层/mnt/propagation安装点并始终使用--propagation unchanged.这可以避免在非 systemd（内核默认值：/是私有的）和 systemd（systemd 默认值：/是共享的）系统上获得不同的实验结果。

和shared

# mount --make-shared /mnt/propagation
# mount /dev/loop0 /mnt/propagation/test
# ls /mnt/propagation/test
lost+found
# cat /proc/self/mountinfo | grep /mnt/propagation/test
862 854 7:0 / /mnt/propagation/test rw,relatime shared:500 - ext4 /dev/loop0 rw

有第二个（根）shell 并取消共享到新的安装命名空间（我将提示符更改为 NMNS# 以区分它）：

# unshare -m --propagation unchanged --
NMNS# cat /proc/self/mountinfo | grep /mnt/propagation/test
1454 1453 7:0 / /mnt/propagation/test rw,relatime shared:500 - ext4 /dev/loop0 rw
NMNS# cd /mnt/propagation/test

同样shared:500链接两个命名空间中的挂载：从一个命名空间卸载将从另一个命名空间卸载它。

在原始 shell 中（在原始挂载命名空间中）卸载它：

# umount /mnt/propagation/test
umount: /mnt/propagation/test: target is busy.

释放资源使用：

NMNS# cd /

# umount /mnt/propagation/test
#

这次成功了。

观察它也消失在新的挂载命名空间中。

NMNS# cat /proc/self/mountinfo | grep /mnt/propagation/test
NMNS#

内核dmesg将记录文件系统已卸载（到处），例如：

EXT4-fs (loop0): unmounting filesystem e74e0353-ace0-4eff-86ae-30e288db853e.

退出新安装命名空间中的 shell 进行清理。

和private

# mount --make-private /mnt/propagation
# mount /dev/loop0 /mnt/propagation/test
# cat /proc/self/mountinfo | grep /mnt/propagation/test
857 854 7:0 / /mnt/propagation/test rw,relatime - ext4 /dev/loop0 rw

不再分享了。

别处：

# unshare -m --propagation unchanged --
NMNS# cat /proc/self/mountinfo | grep /mnt/propagation/test
1454 1453 7:0 / /mnt/propagation/test rw,relatime - ext4 /dev/loop0 rw
NMNS# echo $$
232529

# umount /mnt/propagation/test
# e2fsck /dev/loop0
e2fsck 1.47.0 (5-Feb-2023)
/dev/loop0 is in use.
e2fsck: Cannot continue, aborting.



#

文件系统保持安装在新的安装命名空间中。

要从原始名称空间中找到这个恶意名称空间，可以运行如下命令：

# for pid in $(lsns --noheadings -t mnt -o PID); do nsenter -t "$pid" -m -- findmnt /mnt/propagation/test && echo $pid; done
nsenter: failed to execute findmnt: No such file or directory
TARGET                SOURCE     FSTYPE OPTIONS
/mnt/propagation/test /dev/loop0 ext4   rw,relatime
232529
#

注意：nsenter: failed to execute findmnt: No such file or directory发生的情况是正在运行的 LXC 容器的挂载命名空间findmnt不可用。循环确实在具有挂载点的新命名空间中找到了进程的 PID（注意：在实际情况下，这可能是同一挂载命名空间中的其他 PID，这并不重要。）。在极端情况下，需要一个能够更改挂载命名空间、检查挂载和执行 (u)挂载一体的专用命令。

可以通过删除剩余的持有资源（PID 232529）来删除此安装，如果进程主动使用已安装的文件系统（防止umount成功），则可能需要该资源，或者在此命名空间中卸载它：

# nsenter -t 232529 -m -- umount /mnt/propagation/test
# e2fsck /dev/loop0
e2fsck 1.47.0 (5-Feb-2023)
test: clean, 11/128 files, 58/1024 blocks

有用的参考：

Answer 1

免责声明：我不能也不会在这个答案中解释为什么会触发内核部分故障。这看起来像是一个内核错误，可能是由 I/O 错误条件触发的。

长话短说

当新的挂载命名空间从原始挂载命名空间继承挂载的文件系统时，可能会出现文件系统仍在使用中的情况，但两者之间的传播设置并未使原始命名空间中的卸载将其传播到新命名空间中。该命令findmnt -A -o +PROPAGATION还在其输出中显示每个可见安装点的传播状态。

通常这不应该发生在系统环境，因为系统很早就进行/共享挂载（而不是内核默认的private），从而允许卸载在其共享组内传播。因此，我希望这种情况在非 systemd 环境中更容易发生，或者无论如何，如果工具--make-private在某些安装中明确使用的话。--make-private仍然有其用途，特别是对于虚拟伪文件系统。

防止这种情况发生的一种方法可能是，在创建新的挂载命名空间之前更改与共享的挂载点 mount --make-shared ...。

我做了一个实验来说明共享挂载与非共享挂载会发生什么情况。我试图确保实验在 systemd 或非 systemd 环境中都能同样工作。

实验

这可以像下面一样复制（某些值必须/dev/loop0进行调整）：

# truncate -s $((2**20)) /tmp/test.raw
# mkfs.ext4 -Elazy_itable_init=0,lazy_journal_init=0 -L test /tmp/test.raw
mke2fs 1.47.0 (5-Feb-2023)

Filesystem too small for a journal
Discarding device blocks: done                            
Creating filesystem with 1024 1k blocks and 128 inodes

Allocating group tables: done                            
Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done

# losetup -f --show /tmp/test.raw 
/dev/loop0
# mkdir -p /mnt/propagation/test

这将允许稍后更改实验的传播，而无需通过将目录转变为挂载点来更改整个系统：

# mount --bind /mnt/propagation /mnt/propagation

现在，不同的实验可能会产生不同的结果。

unshare(1)告诉：

unshare因为 util-linux 版本 2.27 会自动将传播设置到private新的挂载命名空间中，以确保新的命名空间确实是非共享的。可以使用选项禁用此功能--propagation unchanged。请注意，这private是内核默认值。

其他工具可能会这样做。在这里，我们将更改底层/mnt/propagation安装点并始终使用--propagation unchanged.这可以避免在非 systemd（内核默认值：/是私有的）和 systemd（systemd 默认值：/是共享的）系统上获得不同的实验结果。

和shared

# mount --make-shared /mnt/propagation
# mount /dev/loop0 /mnt/propagation/test
# ls /mnt/propagation/test
lost+found
# cat /proc/self/mountinfo | grep /mnt/propagation/test
862 854 7:0 / /mnt/propagation/test rw,relatime shared:500 - ext4 /dev/loop0 rw

有第二个（根）shell 并取消共享到新的安装命名空间（我将提示符更改为 NMNS# 以区分它）：

# unshare -m --propagation unchanged --
NMNS# cat /proc/self/mountinfo | grep /mnt/propagation/test
1454 1453 7:0 / /mnt/propagation/test rw,relatime shared:500 - ext4 /dev/loop0 rw
NMNS# cd /mnt/propagation/test

同样shared:500链接两个命名空间中的挂载：从一个命名空间卸载将从另一个命名空间卸载它。

在原始 shell 中（在原始挂载命名空间中）卸载它：

# umount /mnt/propagation/test
umount: /mnt/propagation/test: target is busy.

释放资源使用：

NMNS# cd /

# umount /mnt/propagation/test
#

这次成功了。

观察它也消失在新的挂载命名空间中。

NMNS# cat /proc/self/mountinfo | grep /mnt/propagation/test
NMNS#

内核dmesg将记录文件系统已卸载（到处），例如：

EXT4-fs (loop0): unmounting filesystem e74e0353-ace0-4eff-86ae-30e288db853e.

退出新安装命名空间中的 shell 进行清理。

和private

# mount --make-private /mnt/propagation
# mount /dev/loop0 /mnt/propagation/test
# cat /proc/self/mountinfo | grep /mnt/propagation/test
857 854 7:0 / /mnt/propagation/test rw,relatime - ext4 /dev/loop0 rw

不再分享了。

别处：

# unshare -m --propagation unchanged --
NMNS# cat /proc/self/mountinfo | grep /mnt/propagation/test
1454 1453 7:0 / /mnt/propagation/test rw,relatime - ext4 /dev/loop0 rw
NMNS# echo $$
232529

# umount /mnt/propagation/test
# e2fsck /dev/loop0
e2fsck 1.47.0 (5-Feb-2023)
/dev/loop0 is in use.
e2fsck: Cannot continue, aborting.



#

文件系统保持安装在新的安装命名空间中。

要从原始名称空间中找到这个恶意名称空间，可以运行如下命令：

# for pid in $(lsns --noheadings -t mnt -o PID); do nsenter -t "$pid" -m -- findmnt /mnt/propagation/test && echo $pid; done
nsenter: failed to execute findmnt: No such file or directory
TARGET                SOURCE     FSTYPE OPTIONS
/mnt/propagation/test /dev/loop0 ext4   rw,relatime
232529
#

注意：nsenter: failed to execute findmnt: No such file or directory发生的情况是正在运行的 LXC 容器的挂载命名空间findmnt不可用。循环确实在具有挂载点的新命名空间中找到了进程的 PID（注意：在实际情况下，这可能是同一挂载命名空间中的其他 PID，这并不重要。）。在极端情况下，需要一个能够更改挂载命名空间、检查挂载和执行 (u)挂载一体的专用命令。

可以通过删除剩余的持有资源（PID 232529）来删除此安装，如果进程主动使用已安装的文件系统（防止umount成功），则可能需要该资源，或者在此命名空间中卸载它：

# nsenter -t 232529 -m -- umount /mnt/propagation/test
# e2fsck /dev/loop0
e2fsck 1.47.0 (5-Feb-2023)
test: clean, 11/128 files, 58/1024 blocks

有用的参考：

为什么文件系统已卸载但仍在使用？

答案1

长话短说

实验

相关内容