文件系统为什么变只读
阵列掉盘或出现 IO 错误后，ext4、XFS 这类文件系统可能主动把挂载点切成只读，用这种方式保护剩余数据不再被写入破坏。此时业务侧的典型表现是写入失败、报错提示只读文件系统。处置的重点不是立刻重新挂成读写，而是先保护现场、确认底层阵列的冗余状态。
基本信息
| 触发原因 | 底层 IO 错误、阵列降级或盘掉线 |
|---|---|
| 典型表现 | 写入失败、应用报只读文件系统 |
| 处置重点 | 先确认底层阵列与冗余状态，再决定是否恢复写入 |
| 恢复前提 | 底层问题解决且数据有备份或快照 |
| 权限要求 | root |
处置顺序
- 先确认底层阵列状态，用卡工具或 mdstat 看冗余是否还在
- 确认冗余处在哪种状态：降级但可用，还是已经失效
- 评估业务能否容忍短暂中断，安排数据保护动作
- 恢复写入之前先补齐备份并修复底层问题
- 记录全过程的时间线与操作，便于事后复盘
确认状态与日志
确认状态与日志
dmesg -T | grep -i -E "remount|read-only|I/O error" | tail -30 # 内核侧错误与重挂记录
mount | grep -i " ro," # 列出只读挂载点
cat /proc/mdstat # 软阵列的冗余状态
tune2fs -l /dev/md0 | grep -i "filesystem state" # ext 系列的文件系统状态
storcli /c0/vall show | grep -iE "State|Degraded" # 硬件 RAID 的阵列状态现象与处置
| 现象 | 含义 | 处置方向 |
|---|---|---|
| 文件系统只读 | 内核主动保护 | 先查底层 IO 错误来源 |
| 阵列降级但可用 | 仍能读，风险升高 | 尽快换盘重建并备份 |
| 阵列失效 | 数据不可访问 | 保护现场，寻求数据恢复支持 |
| 错误日志持续增加 | 故障仍在扩散 | 停止写入，避免扩大损坏面 |
底层问题没解决就强制挂回读写：坏块上的写操作会把损失扩散到更多数据。
只读状态也可能由链路问题触发，而不只是盘体故障：把内核日志里 IO 错误的时间点和阵列事件日志对齐，能更快定位到出问题的设备。