Linux findmnt 怎么确认挂载来源：fstab、UUID 与运行时挂载的核对方法

凌晨扩容后，值班同事说“/data 已经挂上了”，但备份任务仍然写进根分区。目录存在并不等于挂载来源正确：它可能是当前内核里的临时挂载，也可能只是 /etc/fstab 里写过一行。要把这件事查准，先让 findmnt 告诉你目标路径对应的设备、文件系统和挂载选项，再分别对照配置文件与运行时记录。

先回答：/data 当前到底挂载了什么

第一条命令只读当前挂载信息，不会修改磁盘或 /etc/fstab：

findmnt --target /data \
  --output TARGET,SOURCE,FSTYPE,OPTIONS

典型结果可能是：

TARGET SOURCE         FSTYPE OPTIONS
/data  /dev/nvme1n1p1 ext4   rw,relatime

这里最重要的是 TARGET 与 SOURCE 的对应关系。若 /data 只是一层普通目录，命令通常不会给出你期待的独立块设备；若它是绑定挂载、网络文件系统或设备映射，SOURCE 也可能不是一个普通分区名。不要只凭目录大小下结论。

用 UUID 把设备名字和持久化身份对上

设备名可能随云主机磁盘顺序变化，UUID 更适合做配置核对。先看当前来源的标签与文件系统：

findmnt --target /data \
  --output SOURCE,UUID,LABEL,FSTYPE,TARGET
lsblk -o NAME,UUID,LABEL,FSTYPE,MOUNTPOINTS

如果 findmnt 返回的 UUID 与 lsblk 中同一设备的 UUID 对不上，先怀疑查询对象或设备映射，而不是马上重建文件系统。重建会改变 UUID，也可能让仍在使用旧来源的配置彻底失效。

对于脚本，建议把列固定下来：

findmnt --target /data --noheadings \
  --output SOURCE,UUID,FSTYPE,TARGET

手册明确提醒，默认输出格式可能变化；显式列名能避免升级 util-linux 后，脚本把某一列误读成设备名。

分别核对 fstab 和运行时记录

当前生效状态与开机配置是两份证据。查 /etc/fstab 时，使用 --fstab 限定数据源，并用 --evaluate 解析 UUID：

findmnt --fstab --evaluate --target /data \
  --output SOURCE,FSTYPE,OPTIONS,TARGET

再回到运行时视角：

findmnt --mtab --target /data \
  --output SOURCE,FSTYPE,OPTIONS,TARGET
findmnt --kernel --target /data \
  --output SOURCE,FSTYPE,OPTIONS,TARGET

如果发行版的 findmnt 版本不接受 --kernel，可以直接读取 /proc/self/mountinfo 做补充核对；不要把不同版本的选项当成完全相同。常见判断有三种：

需要比较多个候选时，怎么选命令

现场排查不需要把所有选项都试一遍。按问题选数据源更快：

• 问“此刻写入 /data 会落到哪里”，优先 --target，必要时加 --kernel。
• 问“重启后应该挂哪块盘”，优先 --fstab --evaluate，再用 lsblk 验证 UUID 是否存在。
• 问“脚本如何稳定取字段”，使用 --noheadings --output，不要解析默认树形文本。
• 问“为什么看起来挂上了却写错盘”，同时保存 fstab、kernel 和业务进程所在命名空间的结果。

三个容易把证据查偏的地方

把目录存在当成挂载成功

创建目录不会产生挂载。用 findmnt --target /data 查不到独立来源时，先检查是否只是根文件系统中的普通目录。

只看 /etc/fstab，不看当前状态

fstab 是启动配置，不是实时快照。临时挂载、容器命名空间和后续人工操作，都可能让当前状态与配置不同。

用默认输出喂给 awk

树形输出适合人眼浏览，不适合接口契约。固定列名后再交给 awk 或监控脚本，并对没有匹配结果的退出状态做处理。

一套不改配置的最终核对流程

1. 先执行 findmnt --target /data --output TARGET,SOURCE,FSTYPE,OPTIONS，保存当前来源。
2. 再执行 findmnt --fstab --evaluate --target /data --output SOURCE,FSTYPE,OPTIONS,TARGET，保存启动意图。
3. 用 lsblk -o NAME,UUID,LABEL,FSTYPE,MOUNTPOINTS 检查 UUID 是否对应同一设备。
4. 最后确认备份进程看到的路径属于同一挂载命名空间；证据一致后，再决定是否需要修改 fstab。

这套顺序的价值在于先回答“现在是什么”，再回答“应该是什么”，最后才讨论“要不要改”。发现不一致不等于可以立即修复，先留住来源、UUID、时间和进程视角，回滚时才不会只剩一个模糊的“挂载失败”。

相关问答

findmnt 能直接修改 fstab 吗？

这里使用的查询选项只读取挂载信息。修改 fstab 仍应走配置变更流程，并在非生产环境验证。

为什么 SOURCE 不是 /dev 开头？

网络文件系统、绑定挂载、设备映射和某些虚拟文件系统都可能使用不同的来源表示，先结合 FSTYPE 与 OPTIONS 判断。

UUID 变了是不是一定要重建文件系统？

不一定。先确认设备、文件系统和配置引用的对象；只有在明确的存储变更场景下，才讨论重建或重新生成 UUID。

最后记住这一条

findmnt 的价值不是替你“修挂载”，而是把目标路径、来源设备、持久化配置和内核当前记录放到同一张证据链上。先固定列、再做对照，绝大多数“写错盘”的误判都能在改配置前被发现。