1. 当硬盘发出"死亡呻吟"时会发生什么？
前两天同事老王慌慌张张跑到我工位："服务器挂了！报了一堆I/O错误！"我淡定地看了眼监控大屏："别慌，肯定是文件系统又掉链子了。"这样的情况在运维生涯里司空见惯——服务器意外断电、硬件突然掉盘、SSD写入量超标，都会让文件系统变成支离破碎的拼图。
2. 文件系统急诊室的常备工具包
（技术栈声明：本文所有示例基于RHEL/CentOS 7+环境）
2.1 传统老将：fsck
这个瑞士军刀般的工具能处理Ext2/3/4系列文件系统。让我用真实案例还原抢救过程：
# 第一步：强制卸载设备（危险操作前必备步骤）
umount /dev/sdb1
# 第二步：自动修复但需要人工确认关键决策
fsck -y /dev/sdb1
# 遇到元数据损坏时的暴力修复（慎用！）
fsck -pcf /dev/sdb1
# 查看修复后的状态报告
fsck -nv /dev/sdb1
这个过程中最有趣的是-y参数，相当于给软件工程师塞了一把巧克力——强制同意所有修复建议。有次我遇到一个企业级NAS，800万inode中有23%损坏，这个参数配合-c选项执行坏块检测，硬是把95%的数据捞了回来。
2.2 XFS专属护卫：xfs_repair
现代数据中心的最爱XFS有自己的运维逻辑，我们来看个典型示例：
# 场景：服务器异常重启导致XFS日志损坏
# 必须检查日志状态（XFS的健康体检）
xfs_db -c "check" /dev/sdc1
# 安全修复模式（温柔的护理）
xfs_repair /dev/sdc1
# 遭遇严重损坏时的强制模式（重症监护）
xfs_repair -L /dev/sdc1
# 事后诸葛亮模式（检查修复效果）
xfs_repair -n /dev/sdc1
上个月某公有云平台的块存储出现集体元数据损坏，正是xfs_repair -L的清空日志操作救了命。这个操作相当于失忆疗法——既然记不清事，就干脆重新开始记录。
3. 解剖工具的适用战场
3.1 fsck的应用地图
传统企业服务器（还在用Ext4的那些老古董）
中小型数据库（单块磁盘就能容纳的表空间）
需要逐块检查的固执场景
上周碰到一个SAS硬盘固件bug导致inode错位，用fsck -cc进行只读坏块扫描避免了二次破坏，配合debugfs成功还原了财务数据库的关键交易记录。
3.2 xfs_repair的优势场景
PB级分布式存储（比如GlusterFS的底层砖块）
高并发日志型业务（订单系统、消息队列）
需要原子操作保证的写密集型应用
去年双十一大促期间，某电商平台的商品图片存储集群出现元数据雪崩，xfs_repair的并行修复能力在15分钟内恢复了200多个存储节点。
4. 工具间的爱恨情仇
比较维度
fsck家族
xfs_repair
检查速度
看表慢查
秒级定位
修复模式
需要大量人工确认
智能决策
元数据保护
存在覆盖风险
有journalling兜底
大文件支持
处理GB级吃力
TB级游刃有余
并行能力
单线程作业
多核并发
就像修车师傅的扳手和智能诊断仪的关系——传统工具需要经验老到，现代工具讲究快速止血。
5. 血泪教训凝结的操作规程
设备脱缰第一定律：所有修复操作必须在umount状态下执行
数据安全黄金准则：dd if=/dev/sdX of=backup.img bs=4M是执行任何修复前的必要仪式
硬件检查优先级：用smartctl确认不是物理损坏才进行软件修复
渐进式修复哲学：从最保守的参数开始，逐步增加修复强度
监控后遗症：修复后需连续72小时跟踪iostat和dmesg
去年某矿企的监控系统磁盘修复，运维小哥忘记检查RAID卡缓存电池，修复后48小时再次崩溃，直接导致井下传感器数据丢失——这就是血的教训。
6. 诊后护理与康复指导
成功的修复只是开始，后续需要：
连续执行xfs_admin -c监控元数据健康度
用badblocks -sv定期扫描物理介质
配置crond定期执行只读检查
在Zabbix等监控系统中添加inode健康度告警
7. 给技术人的终极建议
文件系统的自我修复就像人体的免疫系统——日常体检（检查工具）比急诊手术（修复工具）更重要。建议将以下命令写入运维手册：
# Ext4健康巡检套餐
tune2fs -l /dev/sdX | grep 'Mount count'
e2fsck -f -n /dev/sdX
# XFS健康管理组合拳
xfs_info /dev/sdX
xfs_spaceman -df /dev/sdX
记住：最好的数据恢复是永远不需要恢复！