umount不掉问题解决方案和思路

前言 本文为原创，可能会存在一些知识点或理解上的问题，欢迎切磋和交流  ^_^

前面写过一篇文章，是定位某种业务场景下，因为umount命令失败导致业务中断的问题。如果是极其少的情况下，出现这种内核问题，很有可能是自己代码出的问题，比如操作未释放文件系统引用计数。但是占用文件系统上层服务太多，场景复杂，情况太多，不太可能穷举。针对这种情况，该如何完全解决。

这就要考虑两种解决问题的思路：解决问题和规避问题。前面文章主要是解决问题，定位出问题根因并给出解决方案。本文章主要是从另一个方面进行阐述，就是问题规避。问题规避又分两种情况：架构不变和设计重构。

你整个软件的游戏规则在不能变的情况下，一旦出现问题，从开发角度和系统维护角度分别如何给出规避手段，针对umount不掉问题，能够想到的万能大法就是重启节点。修改产品规格，要求出现这种问题的解决方案是节点重启。但是客户现场大量业务持续跑，重启设备意味着停止客户业务，这是很危险的一个动作，不到万不得已，客户是不会允许的。而且对于我们产品，也不应该是给出这么一个愚蠢的解决方案。

那么，如果从开发角度看，是否可以考虑重构设计，把这个出问题概率极大的流程砍掉，或者进行架构优化，实事证明，这是个极好的思路，可以一了百了，彻底解决问题。设计重构，需要考虑的几点(暂时能想到的就这三点，想到了再补充)：

a. 能否在不影响整体框架前提下，解决问题

这里就要对整个框架业务有所了解或熟悉，知道要修改的模块在整体中的流程。

b. 用户态框架庞大，设计重构，需考虑对其他模块影响

从设计风格来说，不同组件或模块之间最好符合高内聚、低耦合。个人觉得这和函数接口设计原则相一致，模块之间不要杂糅太多，从代码风格和维护上做到简洁。所以这方面是必须要考虑的。

c. 适配其他组件流程

写函数接口的时候，比如其中一个函数执行失败，该如何处理，是直接返回还是先回退之前操作，再回退。同理，组件也要适配相关流程。

小结

寥寥几句，算是对这一类问题的一个小结吧。今天是2019年12月15日，距离19年的结束不到半个月了，umount问题是文件存储最长打交道的一类问题，架构优化的好，理论上完全可以独杜绝掉这个问题，但是不排除有其他的问题出现，所以在即将迎来崭新的旅途上，希望自己可以以一颗平常心，对待发生的一切。加油。