oferge0311

@flyqie 嗯，所以是求助大家有没有更好的思路，目前已经重启一小部分了，后续还不确认要不要继续做。 结合各位老师们给的方案，最简单化影响最小的感觉就是 nofail 了

@q741451 看了一下与克劳德的对话，其实关键就在这里
剩下的不可消除盲区只有两个：NFS export 层的权限拒绝（只能真挂才知道，--ns-test 如果你接受真实访问 NFS ，把脚本里 -t nonfs... 那行删掉即可覆盖）、以及依赖手工操作才存在的设备（这个任何预检都无解，只能靠 lvs/iscsiadm -m node 之类的资产核对，或者干脆接受它，用 nofail 兜底）。
但还是没有办法做到我说的，无实际写操作的影响去检查 fstab 文件。谢谢您了

@adoal 正确的，确实是这样。谢谢您的指点

@anjing01 实在是主机和业务系统太多了，没办法拉取

@valord577 我以肯定的，准确的，不可质疑的回答您，完全不太可能，先不说应用的复杂度，这群人我打个 kernel 补丁包都认为会对他们服务造成影响，要求停止服务后再打补丁 [装个内核补丁包，重启后才会生效]

@coefu 嗯嗯，其实我已经试过 mount -a -v -f 和 findmnt -x -verbose 了，但达不到我的预期，我用最简单的，当它挂载时，我修改 defaults 的 s 删掉改成 defauls ，它们都识别不到，只有 mount -a ，可实际执行 mount -a 更麻烦

@killva4624
1 ）是的，就是因为生产环境不能进行测试，只能从配置文件来分析错误。
2 ）我想要的就是一种方法来进行规模验证，至于优化和推广，这是我前面楼层提到+1 领导需要做的事情了，没那个”实力与公信力“ 出问题反倒一身事。
3 ）而规范 fstab 的写入，其实已经是有标准化配置与流程了，就是运行的年份拉的较长，不知道他们做了什么。而提出业自己的声音进行业务规范，这太难了。做不到的
4 ）确实是扫描一遍全量主机，来去看哪些机器有问题，哪些机器没问题，然后去针对性的修复，这确实是正确的，该走的路线
最后，其实您已经讲明白了我遇到的问题处境和正确的路线，但我其实就是想多了解一种方法，有没有简单化的命令可以应对这种复杂环境来排查。 [我没那个能力写出来，这太难了，感觉已经涉及到内核态了]

@yanqiyu 这个是 chat 帮我根据我的描述写的英文求助帖 [将它发到了 linux.org] ，翻译我又修改了一下，其实问题就在本地的例 sda ，sdb ，sdc 盘总是会出现配置项错误，lv 和 vg 等错误。

@Busy 最开始是跑批测试，灾备环境的内核补丁升级，重启以后所谓的“负责人”压根就说没事，不需要 验证！ 结果后来一周不到出问题，他们就开始”甩“ 说不认，和+2 领导沟通，那他们流程都确认也允许了，也说没问题，现在出这种”甩“，+2 领导说后续再强化一下流程，现在的生产都是确认到”负责人“安排的，实际操作人员验证没问题才算结束的。
至于您说的不可能知晓他们怎么对待挂载点目录的。说的就是我想提前预防一下，避免进救援修机器还麻烦，不像是自己电脑，密码简单，也不会卡顿就进去开弄。