umount不掉问题解决方案和思路
前言 本文为原创,可能会存在一些知识点或理解上的问题,欢迎切磋和交流 ^_^ 前面写过一篇文章,是定位某种业务场景下,因为umount命令失败导致业务中断的问题。如果是极其少的情况下,出现这种内核问题,很有可能是自己代码出的问题,比如操作未释放文件系统引用计数。但是占用文件系统上层服务太多,场景复杂,情况太多,不太可能穷举。针对这种情况,该如何完全解决。 这就要考虑两种解决问题的思路: 解决问题和规避问题 。前面文章主要是解决问题,定位出问题根因并给出解决方案。本文章主要是从另一个方面进行阐述,就是问题规避。问题规避又分两种情况: 架构不变和设计重构 。 你整个软件的游戏规则在不能变的情况下,一旦出现问题,从开发角度和系统维护角度分别如何给出规避手段,针对umount不掉问题,能够想到的万能大法就是重启节点。修改产品规格,要求出现这种问题的解决方案是节点重启。但是客户现场大量业务持续跑,重启设备意味着停止客户业务,这是很危险的一个动作,不到万不得已,客户是不会允许的。而且对于我们产品,也不应该是给出这么一个愚蠢的解决方案。 那么,如果从开发角度看,是否可以考虑重构设计,把这个出问题概率极大的流程砍掉,或者进行架构优化,实事证明,这是个极好的思路,可以一了百了,彻底解决问题。设计重构,需要考虑的几点(暂时能想到的就这三点,想到了再补充): a. 能否在不影响整体框架前提下,解决问题