xfs文件系统修复必须离线操作：先卸载分区（umount /dev/sdxn），再运行xfs_repair /dev/sdxn；若失败可慎用xfs_repair -l清空日志，修复后需用xfs_ncheck验证结构一致性。
服务器文件系统损坏不能靠反复挂载解决，必须离线使用专用工具修复。XFS和ext系列处理方式完全不同，选错工具或在线操作都可能让数据彻底不可逆。
先确认文件系统类型和损坏状态
运行blkid /dev/sdXn查看分区格式，XFS用xfs_info，ext系列用dumpe2fs -h。再查日志：dmesg | grep -E "(xfs|ext4|error|I/O)"，重点找xfs_force_shutdown、I/O error或corrupted字样。如果系统已无法启动，需从Live CD或救援模式进入。
XFS文件系统修复流程
必须确保分区已卸载：umount /dev/sdXn。然后执行基础修复：xfs_repair /dev/sdXn。若返回非0值，说明元数据严重不一致，可尝试清空日志（慎用）：xfs_repair -L /dev/sdXn。注意：-L会丢弃未提交事务，仅在常规修复失败且无备份时使用。修复后用xfs_ncheck /dev/sdXn; echo $?验证，返回0才表示结构正常。
ext系列（ext4/ext3）修复要点
同样需先卸载分区。运行e2fsck -f /dev/sdXn强制检查（-f跳过“干净”标记）。加-y自动确认修复，加-c同时扫描坏块。若提示“journal superblock corruption”，可尝试重建日志：e2fsck -f -j /dev/sdXn。切勿对已挂载的根分区直接运行e2fsck，否则极易引发二次损坏。
修复后必须做的三件事
- 重新挂载并测试读写：mount /dev/sdXn /mnt && touch /mnt/testfile
- 检查底层硬件健康：smartctl -a /dev/sdX看Reallocated_Sector_Ct、UDMA_CRC_Error_Count等关键项
- 核对fstab中UUID是否仍匹配：blkid对比，避免修复后因UUID变更导致下次无法启动
