![为什么 /proc 不能成为 Linux 上的一层覆盖文件系统(overlayfs)?](https://linux22.com/image/113742/%E4%B8%BA%E4%BB%80%E4%B9%88%20%2Fproc%20%E4%B8%8D%E8%83%BD%E6%88%90%E4%B8%BA%20Linux%20%E4%B8%8A%E7%9A%84%E4%B8%80%E5%B1%82%E8%A6%86%E7%9B%96%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%EF%BC%88overlayfs%EF%BC%89%EF%BC%9F.png)
在linux上(4.4.59和4.9.8测试过)运行以下命令会失败:
mkdir -p /tmp/proc
mount -t overlay overlay -o lowerdir=/proc:/tmp/proc /tmp/proc
并且有一条错误消息dmesg
:
overlayfs: maximum fs stacking depth exceeded
为什么不能/proc
是覆盖文件系统的一层?
如果我替换/proc
为/dev
or /sys
,它安装时不会出现问题,所以看起来/proc
.
PS 用例是创建一个更安全的chroot
环境,我/dev
想在.有 2 个已知的解决方法:/sys
/proc
chroot
- 只读绑定挂载。限制是两个命令,而不是必需的一个。
- 只读特殊安装:
mount -t proc -o ro none /tmp/proc
.限制是子安装不会自动映射。
不管怎样,我仍然很好奇为什么/dev
并且/sys
可以很好地使用叠加,但/proc
事实并非如此。
问题已迁移来自堆栈溢出。
答案1
https://github.com/torvalds/linux/commit/e54ad7f1ee263ffa5a2de9c609d58dfa27b21cd9
/*
* procfs isn't actually a stacking filesystem; however, there is
* too much magic going on inside it to permit stacking things on
* top of it
*/
s->s_stack_depth = FILESYSTEM_MAX_STACK_DEPTH;
这可能不是一个信息丰富的答案,但内核开发人员特别不支持它。
答案2
Grepping 中的“深度”/usr/src/linux/fs/overlayfs
发现,这只是针对 的当前堆叠深度的简单检查FILESYSTEM_MAX_STACK_DEPTH
。在包含文件中搜索,发现FILESYSTEM_MAX_STACK_DEPTH
在 中定义为 2 /usr/src/linux/include/linux/fs.h
。评论说
fs堆栈的最大层数。需要限制以防止内核堆栈溢出
显然,因为-filesystem 与orproc
相比增加了另一个间接级别,所以超出了堆栈深度。我没有看到任何明显的原因为什么它不能堆叠得更深,所以尝试增加,重新编译你的内核,看看它是否有效。这可能会导致内核使用更多的堆栈,因此通常需要更多的内存,并且可能会使其变慢 - 我不知道有关实现的详细信息。dev
sys
FILESYSTEM_MAX_STACK_DEPTH
编辑回应评论
我的猜测是proc
文件系统必须跟踪每个模块的文件,因此当模块被删除时它可以删除它们。基本上它是所有模块的覆盖文件系统。但我必须详细阅读源代码才能验证这一点(您也可以阅读源代码。:-)。
堆栈深度属于stack_depth
超级块结构的范围,因此要显示它,您需要某种方法来访问内核数据结构。我想一些内核调试工具可以做到这一点(或者你总是可以编写一个内核扩展/模块来显示它),但我不知道任何具体的方法。