首先要怀疑inode是否耗尽；执行df -i查看iuse%是否达100%，再用ls -a /var/spool/postfix/maildrop | wc -l统计文件数，若超10万则基本锁定为postfix邮件堆积所致，根源多是crontab输出未重定向且mailto=root未关闭。
遇到“No space left on device”但磁盘空间充足，首先要怀疑 inode 是否耗尽。邮件服务（尤其是 Postfix）未正常投递时，会把待发邮件堆积在 /var/spool/postfix/maildrop 目录下——每个邮件对应一个独立小文件，几万封就能吃光整个根分区的 inode。
确认是不是邮件导致的 inode 耗尽
执行以下命令快速验证：
-
df -i—— 查看各挂载点的 inode 使用率，重点关注/或/var的IUse%是否达到 100% -
ls -A /var/spool/postfix/maildrop | wc -l—— 直接统计该目录下文件数，若超过 10 万，基本可锁定问题源 -
mailq或postqueue -p—— 查看 Postfix 邮件队列，若有大量 deferred 或 active 状态邮件，说明投递失败正在持续堆积
定位邮件堆积的根本原因
邮件堆积不是偶然，通常由以下配置或状态引发：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- crontab 定时任务有输出（stdout/stderr），且未重定向，系统默认尝试发邮件给任务所有者（如 root）
- Postfix 或 sendmail 服务未运行、配置错误，或网络策略禁止外发，导致邮件无法投递又不自动丢弃
-
/etc/crontab或/etc/cron.d/下的 MAILTO=root 未关闭，全局启用邮件通知 - root 用户邮箱（
/var/spool/mail/root）过大或损坏，影响 Postfix 后端处理逻辑
清理与长期防护措施
先止血，再防复发：
- 立即清空堆积：
find /var/spool/postfix/maildrop -type f -delete（建议加-maxdepth 1避免误删子目录） - 清空 root 邮箱：
echo > /var/spool/mail/root - 清空 Postfix 队列（谨慎）：
postsuper -d ALL（仅适用于确认无需保留的待发邮件） - 禁用 cron 邮件：在
crontab -e顶部添加MAILTO=""；或统一修改/etc/crontab中的MAILTO=root为MAILTO="" - 为所有定时任务显式重定向输出：
* * * * * /path/to/script.sh > /dev/null 2>&1 - 如无需邮件功能，可停用并屏蔽 Postfix：
systemctl stop postfix && systemctl disable postfix
验证修复效果
执行完清理后，再跑一遍确认步骤：
-
df -i看 IUse% 是否明显下降 -
ls /var/spool/postfix/maildrop | head -3检查是否为空或仅剩极少数文件 - 观察未来 24 小时内该目录文件数是否稳定，避免同类任务再次触发堆积
