什么是 NSFS 文件系统？

Question

内核包含一个文件系统 nsfs。为每个已安装的 snapsnapd创建一个 nsfs 挂载/run/snapd/ns/<snapname>.mnt。ls将其显示为 0 字节文件。

内核源代码似乎不包含任何有关它的文档或注释。主要实现似乎在这里，头文件在这里。

由此看来，它似乎与命名空间有关。

对 repo 的搜索甚至找不到 Kconfig 条目来启用或禁用它...

这个文件系统的目的是什么，用来做什么？

Answer 1

如上面由 jiliagre 链接的内核提交日志所述，nsfs文件系统是一个虚拟文件系统，使 Linux 内核命名空间可用。它与/proc“proc”文件系统分开，其中一些进程目录条目引用nsfs文件系统中的inode以显示某个进程（或线程）当前正在使用哪些命名空间。

在nsfs没有得到列出/proc/filesystems（同时proc做），所以它不能被显式安装。mount -t nsfs ./namespaces因“未知文件系统类型”而失败。这是nsfs因为它与proc文件系统紧密交织在一起。

文件系统类型nsfs仅/proc/$PID/mountinfo在将现有（！）命名空间文件系统链接绑定安装到另一个目标时才变得可见。正如 Stephen Kitt 在上面正确建议的那样，这是为了保持命名空间存在，即使没有进程再使用它们。

例如，使用新的网络命名空间创建一个新的用户命名空间，然后绑定挂载它，然后退出：命名空间仍然存在，但lsns不会找到它，因为它不再被列出/proc/$PID/ns，而是作为（绑定）挂载存在观点。

# bind mount only needs an inode, not necessarily a directory ;)
touch mynetns
# create new network namespace, show its id and then bind-mount it, so it
# is kept existing after the unshare'd bash has terminated.
# output: net:[##########]
NS=$(sudo unshare -n bash -c "readlink /proc/self/ns/net && mount --bind /proc/self/ns/net mynetns") && echo $NS
# notice how lsns cannot see this namespace anymore: no match!
lsns -t net | grep ${NS:5:-1} || echo "lsns: no match for net:[${NS:5:-1}]"
# however, findmnt does locate it on the nsfs...
findmnt -t nsfs | grep ${NS:5:-1} || echo "no match for net:[${NS:5:-1}]"
# output: /home/.../mynetns nsfs[net:[##########]] nsfs rw
# let the namespace go...
echo "unbinding + releasing network namespace"
sudo umount mynetns
findmnt -t nsfs | grep ${NS:5:-1} || echo "findmnt: no match for net:[${NS:5:-1}]"
# clean up
rm mynetns

输出应该类似于这个：

net:[4026532992]
lsns: no match for net:[4026532992]
/home/.../mynetns nsfs[net:[4026532992]] nsfs   rw
unbinding + releasing network namespace
findmnt: no match for net:[4026532992]

请注意，不能通过 nsfs 文件系统创建命名空间，只能通过系统调用clone() ( CLONE_NEW...) 和unshare。该nsfs只反映WRT命名空间当前内核状态，但不能创建或销毁。

正如我们在上面的示例中所探讨的那样，只要没有任何对命名空间的引用，命名空间就会自动被销毁，没有进程（所以没有/proc/$PID/ns/...），也没有绑定安装。

Answer 2

这是setns系统调用使用的“命名空间文件系统”，正如其源代码所示，命名空间相关的 ioctl（例如NS_GET_USERNS，NS_GET_OWNER_UID...）

NSFS伪文件条目过去由/proc文件系统提供，直到 Linux 3.19。这是此更改的提交。

请参阅 Stephen Kitt 关于此文件存在的可能解释的评论。