项目是一个政府内部办公应用，环境是这样的，两个节点，配合深信服的负载均衡器，组成高可用，挂载宏衫存储。

  准备做一次应用更新，手动备份应用，出现了根目录只读。
		![](http://i2.51cto.com/images/blog/201808/21/a4c6059ea312c278b7e79b1c96bca0c2.jpg?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_30,g_se,x_10,y_10,shadow_20,type_ZmFuZ3poZW5naGVpdGk=)
		哎呦，什么情况，这个事情不妙。因为我这直接是root用户，不存在权限问题。
		立即访问通过IP访问应用，发现应用仍然正常！有点摸不着头脑了，第一反应是，立即查看硬盘情况，如下图中，空间还是很富裕的。
![](http://i2.51cto.com/images/blog/201808/21/af0a86fed91c93631240c0936182eb4b.jpg?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_30,g_se,x_10,y_10,shadow_20,type_ZmFuZ3poZW5naGVpdGk=)
		这个情况也有可能是挂载情况，查挂载看看，发现存储挂载正常，而且读写权限正常显示！
		那么问题就奇怪了，挂载点的权限正常，为什么不能写数据呢？带着这个疑问，我在其他的挂载点创建了其他文件，包括存储的挂载点，均正常。
		既然这样，我心里有个思路，根目录出问题了，那问题出在哪里呢。
		没有弄明白，不做其他的操作，是运维最大的保证。在操作前做好应用备份到挂载的存储。
		先重启服务器看看。
		启动好，我后悔了，如果挂载不上，系统会无法启动。
		真让我料到了，系统无法启动，堡垒机等一系列通过ssh登录的系统均无法连接。没有办法了，只能联系系统管理员通过虚拟机管理端登录，系统界面报挂载错误。通过修复模式，进入shell 界面，查看MESSAGE日志，发现出现根目录区域报逻辑块错误。
		![](http://i2.51cto.com/images/blog/201808/21/87c15f8d09e4760e4d584b96235acfb6.jpg?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_30,g_se,x_10,y_10,shadow_20,type_ZmFuZ3poZW5naGVpdGk=)
		挂载根目录后，系统完成启动，SSH服务恢复。
		重新挂载系统，完成了挂载后，问题仍然存在，重启后，没有解决挂载问题。
		那么问题就出在逻辑坏块上，查找了几篇问题处理类似的问题，均是通过重新挂载，或者重新安装系统解决问题。
		联系一个系统内核高手，得到的消息是，系统在加载挂载点时，当发现了系统坏块后，把挂载点直接变成了可读文件系统，但不改系统挂载配置，也就是看到的FSTAB文件以及挂载信息都很正常。
		既然知道了问题出在哪里，那好解决了，处理逻辑坏块有多种方式，选择哪种根据自己的情况而定。
		一般，处理坏块，都是进行标注，让系统自己检查，然后把坏块进行标注，系统在使用过程中不再进行读写。或者通过第三方工具进行修复。就操作难度来说，第一种更合适。同时，还能避免对系统继续写入数据造成更多的坏块。
		这里毕竟情况特殊，选择系统修复。
		如果这个办法无法解决那么在找其他方法修复。避免二次破坏。
		![](http://i2.51cto.com/images/blog/201808/21/c3bd7c726deb968c1a6b546ea6eb5d9d.jpg?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_30,g_se,x_10,y_10,shadow_20,type_ZmFuZ3poZW5naGVpdGk=)
		
		
		修复完成后，系统重启。错误修复成功。
		
		总结：应用在非正常关机，或者存储硬件问题都会出现坏块问题，或者文件系统问题。遇到此类问题，首先一定要稳住心态，戒急戒躁。没有定到问题所在不可做大的修改，和数据的继续写入。首先应该，最打限度的保存现有数据，然后才是修复文件系统。这里我是先停掉应用，备份数据。然后选择修复，同时选择工具时，也要避免对当前情况的最小话的破坏。
		
		同时注重基础知识的学习，FSCK命令使用的很少，出问题了，一般很难想到。建议熟练使用系统工具。