inode 耗尽是“No space left on device”但df -h显示有空间的最常见原因，需用df -i检查IUse%是否100%，再用find定位高inode占用目录。
No space left on device 报错时 df -h 显示还有空间？这不是磁盘真满了，而是 inode 耗尽、被删文件仍占句柄、或挂载点遮挡这三类问题中的某一个在作祟。直接查 df -i，90% 的 case 会立刻定位到根因。
查 inode 是否已满（最常被忽略）
大量小文件（比如 /var/spool/clientmqueue 里的邮件队列、/var/lib/docker/overlay2 的层、/var/log/journal 的二进制日志）会快速吃光 inode，而 df -h 完全不体现这点。
- 运行
df -i，重点关注IUse%列 —— 若达到 100%，就是它了 - 定位高 inode 占用目录：
find /var -xdev -type f | awk -F/ '{d=$1; for(i=2;i - 典型重灾区：
/var/spool/clientmqueue、/var/lib/docker/overlay2、/var/log/journal - 清理前先确认业务影响：比如删
/var/spool/clientmqueue/*前，确保没重要待发邮件；清 journal 日志用journalctl --vacuum-size=100M更安全
查被进程占用的已删文件（du 和 df 统计严重不一致）
文件被 rm 删除，但仍有进程打开着它的 fd，空间不会释放 —— df 显示已满，du 却统计不到，这是最让人困惑的场景。
- 查这类文件：
lsof +L1（只显示 link count 为 0 的已删文件），或lsof | grep deleted - 输出中会看到类似：
nginx 1234 www-data 12w REG 253,0 2.1G 1234567 /var/log/nginx/access.log (deleted) - 对应进程要么重启（如
systemctl restart nginx），要么 kill 后重拉 —— 不要再对(deleted)文件执行rm，那没用 - 某些长期运行的服务（如 Java 应用、数据库）可能缓存日志句柄数天，需结合
lsof -p PID精准定位 fd
查挂载点是否嵌套覆盖（df 和 du 结果差几十 GB）
当一个目录既是物理分区挂载点，又在挂载前存有数据，df 统计的是底层设备，du 统计的是挂载后可见路径 —— 两者严重不一致时，大概率是挂载点“盖住”了原数据。
- 运行
mount，看是否有类似/dev/sdb1 on /data type ext4，同时/data目录下原本就有文件 - 临时卸载验证：
umount /data && du -sh /data && mount /data—— 如果卸载后du突然暴增，说明原数据被挂载遮住了 - 这种情况不能直接删
/data下内容，得先umount，再清理底层残留，否则删的是空目录 - 常见于运维误操作：先建好
/data，再格式化新盘并挂载过去，忘了清空原目录
真正棘手的是混合型问题：比如 inode 已 99% 满，同时又有几个百 MB 的 (deleted) 日志文件被 Java 进程锁着 —— 这时候必须按顺序处理：先 lsof +L1 放掉大块空间缓解症状，再清理 inode 密集区，否则刚腾出一点 inode 又被新日志塞满。
