是inode耗尽；运行df -i查看iuse%是否达100%，再用find和du --inodes定位高密度小文件目录，确认后分批清理并重启占用进程释放inode。
“No space left on device”但 df -h 显示磁盘还有大量剩余？十有八九是 inode 耗尽，不是空间真满了。
怎么确认是不是 inode 用光了
直接跑 df -i，重点看 IUse% 列。只要某个挂载点（比如 /var 或 /home）达到 95% 以上，尤其到 100%，就坐实了 inode 耗尽问题。此时哪怕 df -h 显示还有 40% 空间，touch test、journalctl --vacuum-size 甚至某些服务启动都会失败。
注意：df -i 和 df -h 必须一起看——只看一个会误判。常见错觉是“空间够，为啥写不了”，其实根本不是空间的事。
怎么查哪个目录在疯狂吃 inode
不能靠 ls -lR | wc -l，太慢还容易卡死；也不能只扫一级子目录，小文件往往藏在深层嵌套里。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 从高危路径入手：
find /var -xdev -type f | cut -d/ -f1-4 | sort | uniq -c | sort -nr | head -20，快速定位前 20 个“文件最多”的四级路径 - 盯死这几个典型位置：
/var/spool/postfix/maildrop、/var/log/journal、/var/lib/docker/overlay2、/tmp，它们是生产环境 inode 消耗主力 - 如果怀疑是日志，先用
journalctl --disk-usage看 systemd 日志占了多少 inode，再决定要不要journalctl --vacuum-size=100M
怎么安全删掉几十万个小文件
别用 rm -rf *，会报 Argument list too long 错误；也别直接 find ... -delete，万一路径写错就是灾难。
- 分批删更稳：
find /var/spool/postfix/maildrop -maxdepth 1 -type f -print0 | head -z -n 1000 | xargs -0 rm -f，删完再重复执行，直到输出为空 - 删之前先确认来源：检查
crontab -u root -l，看有没有没重定向输出的脚本，比如* * * * * /usr/bin/ntpdate pool.ntp.org这种——它每分钟生成一封发不出去的邮件，全堆在maildrop里 - 临时缓解可软链接迁移：
mkdir /opt/newmaildrop && chown postfix:postfix /opt/newmaildrop && ln -sfn /opt/newmaildrop /var/spool/postfix/maildrop，把压力转到 inode 充裕的分区
为什么删完文件，df -i 还不降
因为文件被进程打开着。即使你 rm 掉了，只要还有进程持有该文件的 fd，inode 就不会真正释放。
查谁在占着：lsof +L1 列出所有已删除但仍被打开的文件；或者更精准地 lsof /var/spool/postfix/maildrop | grep deleted。通常需要重启对应服务（如 systemctl restart postfix）或整个机器才能彻底回收。
这点最容易被忽略：以为删完就万事大吉，结果 IUse% 纹丝不动——其实是进程还在 hold 着那些“看不见”的 inode。
