磁盘告警时先分开看：空间满和inode满不是一回事

线上机器突然写不了文件，df 一看使用率已经到顶，很多人会直接去删日志。删完发现还是写不进去，或者 df 明明还有几十 GB，创建文件却报 No space left on device。这两种情况要分开查，否则会在错误的方向上浪费时间。

一、先看两列，不要只看 Use%

执行 df -hT 看块设备剩余空间和文件系统类型，再执行 df -i 看 inode 使用率。ext4 默认按容量预分配 inode，小文件特别多的目录会先把 inode 用光，例如邮件队列、缓存碎片、容器 overlay 层和 session 文件。这时 df -h 仍显示剩余空间，但 touch 新文件会失败。xfs 的 inode 是动态分配的，一般不会单独耗尽，但项目配额仍可能让写入失败，报错看起来一样，需要用 xfs_quota -x -c ‘report -h’ 再确认一次。

二、空间真的满了，再找大目录

确认是块空间耗尽后，用 du -xhd1 / 从根开始逐层下钻。加上 -x 是为了避免把挂载进来的其他文件系统算进去。不要一上来对整盘做 du -ah 再排序，整盘排序又慢，还可能把所剩无几的空间再写满。优先看 /var/log、/var/lib/docker、/tmp 和用户家目录。journald 可以用 journalctl --disk-usage 看占用，紧急时用 journalctl --vacuum-size=200M 腾出空间，随后把 SystemMaxUse 写进 /etc/systemd/journald.conf，避免下次再涨回来。

容器场景里，docker system df 能看出镜像、容器和卷各自占多少。未使用的悬空镜像可以用 docker image prune 清理，但正在运行的容器可写层不会被 prune 掉。如果单个容器的日志在 json-file 驱动下涨到数 GB，应在 daemon.json 里限制 max-size 和 max-file，而不是只删一次。

三、删完仍显示满，检查已删除但未释放的文件

进程打开的文件被 rm 之后，目录项没了，空间要等进程关闭文件描述符才归还。用 lsof +L1 找出这类文件。对应进程重启，或者让它重新打开日志后，df 才会下降。在找到并处理之前，不要反复删别的小文件，那解决不了被占用的大块。

四、留下阈值，而不是等人发现

把块使用率和 inode 使用率分成两条告警。块使用率 85% 预警、95% 紧急；inode 使用率到 80% 就该查小文件来源。告警正文里带上文件系统挂载点和类型，值班的人不用再登录才知道该跑 df -h 还是 df -i。磁盘问题大多数不是磁盘坏了，而是某一种资源先到了上限。先把两种上限分开，处理才会快。