oferge0311

@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 领导说后续再强化一下流程，现在的生产都是确认到”负责人“安排的，实际操作人员验证没问题才算结束的。
至于您说的不可能知晓他们怎么对待挂载点目录的。说的就是我想提前预防一下，避免进救援修机器还麻烦，不像是自己电脑，密码简单，也不会卡顿就进去开弄。

@salmon5 是个好的思路方向，可我真正想要做到的是，不去改变当前的相关配置文件去检查，目前看只能使用脚本，去多跑命令来判断返回值了。像您楼下说的，我可能只是在钻牛角头疼自己 [为了重启以后减少工作量和学习新思路]

@Rorysky 是好方法，可以饶过他，但这一步是不好走的，特别在大批量，复杂的情况下

@laminux29 理想的想法，可复杂的生产环境下，甚至做不到全部都与测试灾备环境一致的，业务系统就好几百了。。。