存储层四大隐性故障：IO延迟突增、ext4只读挂载、多路径震荡、tmpfs溢出，均无显性报错但致服务雪崩，需用iostat/dmesg/multipath/df组合诊断。
存储延迟突增导致数据库连接超时
当 io_wait 占用 CPU 超过 30%，或 iostat -x 1 中 %util 持续接近 100%、await 超过 50ms，MySQL/PostgreSQL 常出现 Lost connection to MySQL server during query 或 could not receive data from server。这不是网络问题，而是存储层响应太慢，连接池耗尽或客户端主动断开。
实操建议：
- 用
iotop -oPa定位具体进程和 I/O 模式（如大量READ还是WRITE_SYNC） - 检查是否启用了
barrier=1或data=ordered的 ext4 挂载选项——在机械盘或旧 RAID 卡上会显著拖慢 fsync - 确认业务是否在非事务场景误用了
INSERT ... SELECT或未加LIMIT的大范围UPDATE，这类操作会持续占满 I/O 队列
ext4 文件系统只读挂载引发服务静默失败
ext4 filesystem is mounted read-only 不一定伴随明显报错，但任何写入操作（如日志轮转、临时文件生成、session 存储）都会失败。Node.js 的 fs.writeFile、Python 的 open(..., 'a') 会抛 EROFS，但若未捕获异常，进程可能继续运行却不再落盘。
实操建议：
- 立即检查
dmesg | grep -i "ext4\|error\|readonly"，常见原因是磁盘坏道、RAID 降级或 journal 损坏 - 避免直接
mount -o remount,rw—— 若 journal 已损坏，强制重挂可能导致元数据不一致；应先e2fsck -n /dev/sdX1验证，再决定是否-y修复 - 监控项必须包含
cat /proc/mounts | grep 'ro,'，而不仅是磁盘空间或 inode 使用率
多路径设备重复注册造成 I/O 路径震荡
在使用 device-mapper-multipath 的 SAN 环境中，若 /etc/multipath.conf 配置错误（如 wwid 匹配不全、blacklist 漏掉 HBA 卡设备），会导致同一 LUN 被识别为多个 dm-* 设备。上层应用（如 LVM 或容器存储插件）可能随机绑定到某条路径，当该路径因交换机抖动断开，I/O 就卡住数秒甚至触发 timeout。
