Linux /proc/self/mountinfo 怎样解析挂载点字段

排查容器里的路径为什么和宿主机不一致时，很多人第一反应是看 /proc/mounts。如果还要知道挂载树的父子关系、bind 挂载在文件系统中的根目录，或者某个挂载是否参与 shared/slave 传播，更适合读取 /proc/self/mountinfo。关键不是把整行按固定下标硬拆，而是先找到中间那个独立的 - 分隔符。

官方文档：https://www.kernel.org/doc/html/latest/filesystems/proc.html#proc-pid-mountinfo-information-about-mounts

一行 mountinfo 可以稳定地分成两部分：分隔符左侧是挂载树、路径和单挂载属性，右侧是文件系统类型、挂载源和超级块属性。左侧的可选字段数量不固定，所以解析时必须以分隔符为锚点，而不是假定某个字段永远位于同一个位置。

先区分 mountinfo 与 mounts

/proc/self/mountinfo 描述的是当前进程所在挂载命名空间中的挂载记录。它补充了较旧挂载列表中缺少的内容，例如每个挂载的 ID、父挂载、bind 挂载的 root，以及 shared、master 等传播状态。这里的“当前进程”很重要：进入另一个 mount namespace 的进程，看到的记录可能不同。

只想快速观察当前命名空间，可以先用下面的命令。它只负责读取文本，不把输出当作稳定的机器接口。

# 只查看当前进程命名空间中的前几条挂载记录
sed -n '1,3p' /proc/self/mountinfo

# 只筛选挂载点路径，便于先定位目标记录
grep -F ' /var/lib ' /proc/self/mountinfo

不要把 /proc/mounts、/proc/self/mounts 和 mountinfo 的字段布局混用。本文只讨论后者的一行格式。

一行 mountinfo 到底包含哪些字段

内核文档给出的记录可以抽象成下面的结构：

36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue

分隔符左侧从前到后可以这样读：

这里有两个容易误读的地方。第一，root 不是进程看到的完整挂载点；bind 挂载可能只把底层文件系统的一部分目录映射出来。第二，mount options 与最后的 super options 作用域不同，不能看到同一个 rw 就断定它们代表完全相同的配置。

为什么要以连字符为解析边界

可选字段位于固定字段之后，数量会因为传播属性、挂载状态和内核扩展而变化。最稳妥的做法是把原始行拆成“第一个独立的 - 左侧”和右侧两段：左侧前六项固定，剩余项全部暂存为可选字段；右侧再按文件系统类型、挂载源和超级块选项解释。

import re

def unescape_mountinfo(value: str) -> str:
    # mountinfo 用三位八进制转义空格、制表符和反斜杠
    def replace(match: re.Match[str]) -> str:
        return chr(int(match.group(1), 8))
    return re.sub(r"\\([0-7]{3})", replace, value)

def parse_mountinfo(line: str) -> dict[str, object]:
    # 连字符右侧是稳定锚点，不能用固定位置猜 optional fields 的数量
    left, right = line.rstrip("\n").split(" - ", 1)
    left_fields = left.split()
    right_fields = right.split()
    if len(left_fields) 

这个示例只做文本结构解析。对于生产脚本，还应把无法转换为整数的 ID、缺失分隔符和未知的右侧扩展当作输入错误处理，而不是静默取错字段。

解释分隔符后的三组信息

分隔符右侧至少有三部分：文件系统类型、挂载源和超级块选项。以示例记录为例，ext3 是文件系统类型，/dev/root 是挂载源，rw,errors=continue 是超级块级别的选项。

因此，解析器不应该把右侧所有内容重新拼成一个“挂载选项”字段。前面的 rw,noatime 是 per-mount 选项，最后的 rw,errors=continue 是 per-superblock 选项；两组参数可能有重叠名称，但判断影响范围时必须保留它们的来源。

用 parent ID 和传播字段理解挂载关系

parent ID 让每条记录可以挂到挂载树上。它描述的是挂载对象的父节点，不等于目录字符串的父路径。路径字符串发生变化、存在 bind 挂载或处于不同命名空间时，单看字符串很容易得出错误结论。

可选字段中，shared:X 表示当前挂载属于某个 shared peer group，master:X 表示它是某个 peer group 的从属关系。解析时应把这些字段当作标签保存，未知标签也不要因为没有见过就丢弃。

# 只从记录文本中抽取传播标签，不假设标签一定存在
# 先找独立的连字符，再扫描它前面的可选字段
awk '{
  separator = 0
  for (i = 1; i 

上面的命令适合解释思路，但它没有处理所有路径转义和复杂输入。需要长期运行的工具应采用前面的 Python 版本，或直接使用已经理解 mountinfo 格式的系统库。

常见误区与采用建议

• 误区一：固定取第 6 项之后的字段。可选字段数量不是协议中的固定列，必须先找到 - 。
• 误区二：把 root 当成挂载点。root 描述底层文件系统中的起点，mount point 才是当前进程看到的挂载位置。
• 误区三：把两组 options 合并。保留 per-mount 与 superblock 两个作用域，排障结论才不会扩大影响范围。
• 误区四：只按字符串比较路径。需要结合 mount ID、parent ID 和命名空间视角判断挂载关系。

如果只是临时排查，先用命令定位目标记录，再手工查看分隔符两侧；如果要写监控、容器诊断或系统巡检工具，则应使用“固定前六项 + 可变可选字段 + 连字符右侧三组”的数据模型，并为未知可选标签保留扩展空间。

相关问题

mountinfo 中的 mount ID 会永久不变吗？

不会。它是当前挂载记录的标识，卸载后可能被复用。跨时间比较时不能只凭 mount ID 判定同一个历史挂载。

为什么 mount point 和 root 可能都像路径？

两者都以路径形式出现，但前者是挂载点相对进程根目录的位置，后者是该挂载在底层文件系统中的根。bind 挂载时这个差异尤其明显。

读取 /proc/其他 PID/mountinfo 有什么不同？

它反映目标进程所在的挂载命名空间，并受对应 proc 访问权限影响。当前进程的 /proc/self/mountinfo 只代表当前视角。