FSCK 修复 Read-only file system 造成数据丢失的场景记录

承接《EXT3 存储设备最大挂载次数告警解决》最后一句话的梗：

1° 测试库主机掉电，数据盘 Read-only
使用fsck之后所有数据文件名乱码，是否丢失数据文件未知
包括备份文件在内的所有数据文件均无法识别，无法恢复
最终的解决方案是测试库重建，投诉园区，办公开发环境停滞将近一周

2° 某公司的图片和小文件服务器所在机房环境掉电，数据盘 Read-only
使用fsck之后所有数据丢失，该公司错误使用EXT文件系统存储了大量小文件
并且掉电时间在业务高峰，高负载的图片存取行为对数据盘inode造成极高压力
掉电后inode信息错乱，数据盘无法再次挂载，fsck后数据全部丢失
最终结果是这一部分生产数据真的丢了…

简单总结
以上两个例子(其实还有更多)，均包含了两个因素：
一是磁盘高速读写，压力过高
二是掉电，磁盘读写行为急停
当然第二个列子还存在业务功能不合理的情形
和当前公司在我进行FastDFS改造之前情形相类似
第一个因素需要衡量重要性，做切分或者使用高可用架构解决
第二个因素，人为过失引起的天灾(还有诸如机房被灌水、光纤被挖断的例子)，无解