“No space left on device”但df -h显示空间充足，通常是inode耗尽而非磁盘块满；需用df -i确认IUse%是否达100%，重点检查/var、/tmp、/home等独立挂载点，并分层定位高inode占用目录，清理时注意避免rm *报错、已删文件被进程占用未释放、定时任务持续生成小文件等问题。
“No space left on device”但 df -h 显示空间充足？十有八九是 df -i 暴露的 inode 耗尽问题，不是磁盘块满，而是文件“身份证”发完了。
用 df -i 确认是不是 inode 真的用光了
别跳过这步——很多故障排查卡在“以为是空间问题”，其实 df -h 和 df -i 查的是两套资源，互不替代：
-
df -i输出里看IUse%列：只要任意挂载点显示100%，就坐实 inode 耗尽 - 重点盯
/var、/tmp、/home这些独立挂载点，它们各有各的 inode 池，/ 分区正常 ≠ 其他分区安全 - 加
-T参数（df -i -T）能顺带看到文件系统类型，ext4 默认 inode 数量跟格式化时的块大小策略强相关，XFS 则动态分配，表现不同
快速定位哪个目录在疯狂吃 inode
全盘 find / | wc -l 太慢还可能卡死，要分层聚焦：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 先对可疑挂载点做粗筛：
du --inodes -s /var/* 2>/dev/null | sort -nr | head -5—— 第一列数字越大，说明该子目录占的 inode 越多 - 如果发现
/var/spool/postfix/maildrop或/var/spool/clientmqueue异常高，直接进目录：find . -maxdepth 1 -type f | wc -l确认是否几十万小文件 -
ncdu -x /var（需安装）按Shift+I切换到 inode 视图，比纯命令更直观，但生产环境没装 ncdu 就别等它了
清理时最常踩的三个坑
删完文件，df -i 的 IUse% 还是 100%？多半掉进下面这些坑里：
- 用
rm *清理海量小文件会报Argument list too long错误，必须改用ls | xargs -n 1000 rm -f或find . -type f -delete - 已删除但被进程占用的文件（
lsof +L1或lsof | grep deleted可查），inode 不会真正释放，得重启对应服务（如systemctl restart postfix）或杀进程 - 定时任务（比如每分钟执行的 cron）输出未重定向，失败邮件堆在
/var/spool/下，不修 crontab 就算清完也会复发
为什么清理完还是容易再爆
根本原因不在“删不删”，而在“谁在造”和“有没有控”：
- logrotate 配置缺失或
daily没生效，日志不轮转 → 小文件越积越多 - Docker 容器日志没限制（
docker run --log-opt max-size=10m --log-opt max-file=3），/var/lib/docker/containers/下全是.log碎片 - 监控缺位：Prometheus + node_exporter 的
node_filesystem_files_free指标或 Zabbix 的df.inode监控没设阈值（建议 85% 告警），等爆了才人工登录
真正难的不是第一次清理，而是让 df -i 的 IUse% 再也没机会摸到 100% —— 这需要从应用行为、日志策略、监控闭环三处同时动手。
