Linux 磁盘故障场景化排查与修复（8 大故障场景完整解决方案）

来源：Bob小课堂（微信公众号）| 发布日期：2026-07-09 定位：按故障现象直接对号入座的修复手册——只读文件系统、超级块损坏、Inode 耗尽、坏道、盘符漂移、挂载夯住、LVM 故障、救援模式 8 大场景，每个场景给「现象 → 成因 → 命令级解决方案」。分区/挂载/LVM 的日常操作手册见 linux-disk-partition-mount-guide，空间排查见 linux-disk-space-troubleshooting，SMART 健康预测见 linux-smart-disk-failure-prediction。

磁盘故障是高级系统运维处理频率最高的底层故障之一，通常分为文件系统逻辑故障、物理硬件坏道、资源耗尽和挂载/识别异常四大类。本文按生产环境实战经验给出每类的完整排查与解决方案。

前置运维铁律（务必遵守）

故障处理三原则：

1. 不要随意重启 — 异常关机或重启可能加剧文件系统损坏
2. 先卸后修 — 修复文件系统前，必须将分区 umount（根分区除外，需进入救援模式）
3. 操作前备份元数据 — 修复前建议用 dd 备份超级块和分区表：dd if=/dev/sda of=/backup/mbr.bak bs=512 count=1

场景 1：文件系统只读（Read-Only File System）

现象： touch test 报错 Read-only file system，dmesg 中常伴有 EXT4-fs error 或 Buffer I/O error。

1.1 异常关机/非正常重启导致（日志回放失败）

成因： 系统意外断电，日志（Journal）数据损坏或未完整回放，内核为保护数据一致性强制置为只读。

解决方案（在线修复优先）：

# 1. 查看只读分区（通常为 / 或 /data）
mount | grep "ro,"
# 2. 尝试强制重新挂载为读写（针对非根分区）
mount -o remount,rw /dev/sdb1 /mnt/data
# 若上述命令报错 "cannot remount ... read-only"，则必须卸载修复
# 3. 针对根分区（/）只读 — 必须重启进入救援/单用户模式
systemctl reboot
# 在 GRUB 启动项按 'e' 编辑，在 linux 行末添加 rd.break 或 init=/bin/bash
# 重新挂载根为读写：
mount -o remount,rw /sysroot
# 执行日志恢复：
e2fsck -fy /dev/mapper/centos-root

1.2 文件系统日志（Journal）损坏修复

# 卸载故障分区（若为根分区，需用 Live CD 或救援模式）
umount /dev/sda3
# 强制检查并修复（-f 强制检测，-y 自动 yes）
fsck.ext4 -fy /dev/sda3
# 若超级块正常但日志异常，可尝试清除日志并重建
fsck.ext4 -fy /dev/sda3
tune2fs -O ^has_journal /dev/sda3   # 关闭日志
fsck.ext4 -fy /dev/sda3
tune2fs -O has_journal /dev/sda3    # 重建日志
# 重新挂载验证
mount /dev/sda3 /mnt/data

场景 2：文件系统超级块（Superblock）损坏

现象： mount 报错 Structure needs cleaning 或 can't read superblock。

解决方案（利用备份超级块恢复）：

# 1. 查看该分区的超级块备份位置（需知道块大小，通常为 1024/2048/4096）
mkfs.ext4 -n /dev/sda3
# -n 表示不真正格式化，仅打印备份超级块位置
# 输出示例：
# Superblock backups stored on blocks:
#   32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
# 2. 使用最近的备份超级块修复（例如备份块 32768）
fsck.ext4 -b 32768 -y /dev/sda3
# 3. 修复完成后，重新挂载
mount /dev/sda3 /mnt/data

场景 3：磁盘空间未满但无法写入（Inode 耗尽）

现象： df -h 显示空间尚有剩余，但创建文件报错 No space left on device。

排查与解决：

# 1. 查看 Inode 使用率（关键指标）
df -i
# Filesystem   Inodes  IUsed  IFree IUse% Mounted on
# /dev/sdb1    5242880 5242880      0  100% /var/log
# 2. 查找包含海量小文件的目录（通常是日志、Mail、Squid 缓存、Session 文件）
find /var/log -type f | wc -l
find /var/spool/postfix/maildrop/ -type f | wc -l   # 常见陷阱
# 3. 解决方案：清理无效文件或增加 Inode（需卸载，极少数情况支持在线扩容）
# 删除大量小文件（若数量极大，使用 rsync 技巧加速删除）
rsync -av --delete /empty/ /var/log/nginx/cache/
# 或使用 find + 管道删除（慎用，负载高）
find /var/log/ -name "*.log" -mtime +30 -delete
# 若 Inode 天生不足，需备份数据后重新格式化并指定 -N 参数
mkfs.ext4 -N 8000000 /dev/sdb1   # 指定 Inode 数量为 800 万

关联深挖：df 有余量但删文件不释放的「幽灵文件」场景是另一类问题，见 linux-deleted-file-disk-space-reclaim；批量小文件删除技巧见 linux-mass-file-deletion-guide。

场景 4：磁盘 I/O 错误 / 坏道（Hardware Error / Bad Block）

现象： dmesg 输出 end_request: I/O error, dev sda, sector 123456，/var/log/messages 大量 scsi 错误，应用卡顿。

4.1 使用 SMART 检测物理健康状态

# 查看磁盘整体健康评估（重点关注 Reallocated_Sector_Ct 和 Current_Pending_Sector）
yum install smartmontools -y   # 或 dnf install
smartctl -a /dev/sda
# 执行快速自检
smartctl -t short /dev/sda
# 查看自检结果
smartctl -l selftest /dev/sda

SMART 六大高危指标判读与故障预测模型见 linux-smart-disk-failure-prediction。

4.2 处理逻辑/物理坏道

# 1. 尝试读写修复（让磁盘重新映射保留扇区）
badblocks -sv /dev/sda > /root/badblocks.txt   # 扫描坏道
# 2. 修复（尝试强制写坏道，触发 remap）
dd if=/dev/zero of=/dev/sda bs=4k seek=123456 count=1 conv=noerror,sync
# 3. 若坏道集中在某个分区，使用 fsck 标记坏块，使其不再使用
fsck.ext4 -l /root/badblocks.txt -y /dev/sda1
# -l 将坏道列表加入系统黑名单

4.3 紧急数据抢救（使用 ddrescue）

# 当磁盘有物理损坏时，切忌使用 dd，必须使用 ddrescue 跳过坏块
yum install ddrescue -y
ddrescue -f -n /dev/sda /dev/sdb /root/rescue.map   # 第一次拷贝，跳过坏块
ddrescue -f -r 3 /dev/sda /dev/sdb /root/rescue.map # 再次尝试深度复读坏块

ddrescue 在取证镜像场景的完整用法见 linux-rm-rf-ops-recovery-handbook。

场景 5：磁盘设备识别异常 / UUID 冲突 / 盘符漂移

现象： 重启后 /dev/sda 变成了 /dev/sdb，系统无法挂载 /etc/fstab 中的目录，进入紧急模式（Emergency Mode）。

解决方案（强依赖 UUID）：

# 1. 紧急救援模式下，查看所有分区的 UUID
blkid
# 2. 编辑 /etc/fstab，将 /dev/sdX 路径全部替换为 UUID
vi /etc/fstab
# 修改前：/dev/sda1  /boot  ext4  defaults  0 0
# 修改后：UUID=xxxx-xxxx-xxxx  /boot  ext4  defaults  0 0
# 3. 重新生成 GRUB 引导（若是根分区变更）
grub2-mkconfig -o /boot/grub2/grub.cfg
# 4. 若因多路径（MPIO）或 iSCSI 导致设备乱序，建议安装并使用 multipath 管理
systemctl start multipathd
mpathconf --enable

紧急模式的完整排查步骤与 fstab 修法见 linux-disk-partition-mount-guide 案例三。

场景 6：磁盘挂载进程夯住（D 状态进程 / 卡死）

现象： 执行 df -h 或 ls 挂载目录时终端卡死无法 Ctrl+C，ps aux 显示进程状态为 D (Uninterruptible Sleep)。

解决方案（切忌 kill -9，D 状态无法被杀）：

# 1. 查看当前挂载点的进程占用
lsof +D /mnt/data
fuser -mv /mnt/data
# 2. 强制卸载（延迟卸载，-l 懒卸载，断开文件系统与 VFS 的关联）
umount -l /mnt/data
# 3. 卸载后，查看哪个进程还握着句柄（这些进程需重启）
lsof | grep '(deleted)' | grep /mnt/data
# 重启这些持有句柄的服务（如 NFS、数据库、日志服务）
# 4. 如果 umount -l 仍无法处理，尝试重新挂载为只读后再卸载
mount -o remount,ro /mnt/data
umount /mnt/data

D 状态进程与 Load Average 的关系深挖见 linux-load-average-guide、linux-load-high-cpu-low-troubleshooting。

场景 7：LVM 逻辑卷故障（VG 丢失 / PV 损坏）

现象： lvdisplay 无输出，vgchange -ay 报错 No volume groups found 或 Input/output error。

恢复流程：

# 1. 扫描所有 PV（物理卷）
pvscan
# 2. 尝试强制恢复 VG 元数据（从 /etc/lvm/backup/ 或 /etc/lvm/archive/ 还原）
vgcfgrestore -f /etc/lvm/backup/vg_centos -n vg_centos /dev/sda2
# 3. 若元数据区损坏，尝试使用 vgck（检查并修复卷组一致性）
vgck --updatemetadata vg_centos
# 4. 激活卷组
vgchange -ay
# 5. 若 PV 丢失，尝试重新创建 PV 不丢失数据（使用 pvcreate 恢复 UUID）
pvcreate --uuid --restorefile /etc/lvm/backup/vg_centos /dev/sda2

LVM 分层架构与日常管理见 linux-raid-lvm-basics-guide；大容量 RAID 5 重建风险见 linux-raid5-rebuild-risk-guide。

场景 8：运维终极保底方案 — 系统救援模式（Rescue Mode）

当 / 分区损坏且无法进入系统时，使用 CentOS Stream / RHEL 安装 ISO 启动：

1. 选择 Troubleshooting → Rescue a CentOS Stream system
2. 挂载系统为读写：mount -o remount,rw /mnt/sysimage
3. 切换根环境：chroot /mnt/sysimage
4. 执行上述各类 fsck 修复操作

日常预防性巡检清单（SRE 必备）

原文此节为表格截图（已存 raw/assets/2026-09-07-disk-fault-checklist-table.png），内容按 OCR 还原：

iostat 阈值体系详见 linux-disk-io-monitoring-reference 与 linux-disk-inspection-tools-guide；SMART 指标预测模型见 linux-smart-disk-failure-prediction；journalctl 用法见 journalctl-log-tracking-guide。

总结

• 大多数磁盘「只读」故障并非物理坏道，而是文件系统脏标志（Dirty Flag）未清除
• fsck 是解决 90% 逻辑故障的「银弹」，但务必在卸载（umount）状态下执行
• 对于生产环境核心业务数据库（如 MySQL / PostgreSQL）所在的磁盘，若出现坏道，优先使用 mysqldump 或 pg_dump 逻辑导出恢复，而非在坏盘上执行 fsck -y，以免数据错乱导致无法恢复

关联页面