关于/etc/mtab相对符号链接的疑问及ZFS根文件系统下NFS故障排查后的技术咨询

我太懂你排查这个NFS故障时的崩溃感了——折腾几个小时发现是rpc.mountd崩溃，最后溯源到/etc/mtab的链接问题，确实挺绕的。下面针对你的三个问题逐一拆解：

1. 为什么/etc/mtab是相对链接？是为了简化chroot场景吗？ #

没错，相对链接的设计核心就是为了兼容chroot环境。Debian系系统默认用../proc/self/mounts这个相对路径，是因为当你把系统chroot到某个目录（比如系统修复、容器隔离场景）时，相对链接会自动适配chroot后的文件系统结构，指向当前chroot环境里的/proc/self/mounts，而不是宿主系统的路径。如果用绝对链接，chroot后/etc/mtab会依然指向宿主的/proc/self/mounts，完全失去了在chroot里查看挂载信息的作用。

2. 把它改成绝对链接有问题吗？ #

一般来说，在你的使用场景下完全没问题——毕竟改成绝对链接直接解决了NFS的故障。但要注意一个潜在的场景：如果之后需要在这台服务器上使用chroot（比如修复系统、运行依赖chroot的服务），这个绝对链接会失效：chroot环境里的/etc/mtab会指向宿主系统的/proc/self/mounts，而不是chroot内部的挂载信息。不过如果你的服务器主要是跑Proxmox和NFS，平时用不到chroot，那这个问题完全可以忽略。

3. ZFS（假设它是根因）怎么会破坏这个链接？ #

这和ZFS根文件系统的启动挂载顺序有关。普通ext4这类文件系统启动时，根文件系统挂载完成后，/proc会很快被挂载到位，此时/etc/mtab的相对链接../proc/self/mounts能正常解析到正确路径。但ZFS根系统的启动流程有特殊性：

• ZFS挂载根文件系统的时机可能早于/proc的挂载，或者在rpc.mountd启动的那个初始化阶段，进程的上下文路径解析逻辑和普通文件系统不同；
• 当rpc.mountd尝试读取/etc/mtab时，相对链接无法正确解析到实际的/proc/self/mounts，导致读取失败，进而引发段错误（segfault），最终让NFS挂载请求超时。

简单说就是ZFS根系统的启动流程让这个相对链接在服务初始化时“找不到北”了。

备注：内容来源于stack exchange，提问作者Philipp Burch