存储层四大隐性故障：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。
实操建议：
- 运行
multipath -ll，确认每个 LUN 是否只对应一个mpath*名称，且status=active的路径数 ≥2 - 检查
/var/log/messages中是否有device-mapper: multipath: checker failed或path already in use - 禁用内核自动扫描：在
/etc/default/grub中添加rd.multipath=on rd.md=0 rd.lvm=0，防止 initramfs 阶段误启用 md/lvm 干扰 multipath
tmpfs 内存溢出导致 OOM Killer 杀死关键进程
tmpfs 看似“内存文件系统”，但其大小受 mem= 和 swappiness 共同影响。当 /dev/shm 或 /run 被应用（如 redis 的 appendonly.aof 临时写入、docker 构建缓存）撑满，内核会尝试 swap，若 swap 分区不足或 vm.swappiness=0，就直接触发 OOM Killer —— 未必杀占用内存最多的进程，而是根据 oom_score_adj 和内存分配压力综合判断。
实操建议：
- 用
df -h /dev/shm /run和find /dev/shm -type f -size +10M快速定位大文件 - 限制 tmpfs 大小：挂载时显式指定
size=2G，例如mount -t tmpfs -o size=2G tmpfs /dev/shm - 避免在 tmpfs 中存放持久化数据；Redis 应配置
appendonly no或将 AOF 写入真实磁盘分区
存储层的问题从来不在“能不能用”，而在“什么时候不可用”和“为什么看起来还能用”。延迟毛刺、只读切换、路径漂移、内存假象——这些状态往往没有 ERROR 日志，却能让业务在低峰期突然雪崩。盯住 iostat、dmesg、multipath -ll 和 df -h 的组合输出，比任何监控大盘都管用。