文件系统选型出问题时的排查顺序:从现象到根因

Linux · 3 分钟阅读· 63 次阅读

Btrfs 的 df 显示原始容量,btrfs filesystem usage 才是真实可用

正确的第一步是分类:起不来、连不上、跑得慢,三条路完全不同。

先说结论

先分三类,再由外向内查:网络、进程、配置、依赖、资源。

  • 先确认现象能复现,且能描述清楚
  • 由外向内:端口、进程、配置、依赖、资源
  • 读第一条错误,不是最后一条
  • 改一个变量,验证一次,别一次改五处
  • 留下记录:现象、假设、验证、结论

第一类:起不来

先看进程在不在,再看它为什么退出:Btrfs 的 df 显示原始容量,btrfs filesystem usage 才是真实可用。

  • 查看服务状态与最近日志(不是全部日志)
  • 确认端口是否被占用、权限是否足够
  • 确认配置文件语法(多数服务支持 test 模式)
  • 确认依赖的数据目录存在且可写

第二类:连不上

按「本机、网络、代理、应用」四层查:

层级 验证方式 典型原因
本机 本机 curl / telnet 端口 没监听、只听 127.0.0.1
网络 从另一台机器访问 防火墙、安全组、VLAN
代理 检查反代配置与证书 路径、超时、头部大小
应用 看访问日志与错误日志 鉴权、限流、连接池耗尽

第三类:跑得慢

noatime 能省掉大量元数据写入,数据库和桌面都建议开。

慢的问题先分清是「等」还是「算」:CPU 高是算,CPU 低但延迟高是等(IO、锁、网络)。

文件系统选型出问题时的排查顺序

这个服务的高频故障点

同类的坑基本集中在这些位置:

  • XFS 只能扩不能缩,分区规划错了只能备份出来重建
  • Btrfs 的 df 显示原始容量,btrfs filesystem usage 才是真实可用
  • noatime 能省掉大量元数据写入,数据库和桌面都建议开
  • ZFS 的 ARC 会吃掉大部分空闲内存,free 只剩几百 MB 属于正常

别做的事

用 Btrfs 组 RAID5,掉一块盘后校验和报出一片错

mkfs 时没调 inode 比例,邮件队列把小文件 inode 用光

一次改多个参数,会让下一次故障更难查。

把结论写下来

排查记录不是给别人看的,是给三个月后的自己看的。ZFS 的 ARC 会吃掉大部分空闲内存,free 只剩几百 MB 属于正常。

排障能力不是知道更多命令,是知道先查什么。

评论 (3)

南
南风

「先看日志再猜」这句话值一篇文。

老
老吴

备份没验证过等于没有,这条我认。

L
lin

最小可用配置这个说法很好,先跑起来再优化。

发表评论

验证码

提交后需站长审核,通过后才会显示。