df命令仅提供瞬时快照，无内置历史记录功能；需通过crontab定时执行df -h --output=source,size,used,avail,pcent,target并配合grep过滤、时间戳记录及日志存储，才能实现磁盘使用趋势分析。
df 命令本身不记录历史，但可以手动采集趋势
df 是瞬时快照工具，每次运行只返回当前状态，没有内置日志或时间序列功能。想看“趋势”，必须自己定期采集数据并保存对比。
常见做法是用 crontab 每小时执行一次：df -h --output=source,size,used,avail,pcent,target | grep "^/dev/" >> /var/log/df-history.log
- 加
--output可控字段顺序，避免列对齐错乱影响后续解析 - 用
grep "^/dev/"过滤掉tmpfs、devtmpfs等虚拟文件系统，聚焦真实磁盘分区 - 务必写入有写权限的日志路径（如
/var/log/），别用~/—— cron 默认以 root 或服务用户运行，家目录可能不可写 - 建议加时间戳：在命令前加
echo "$(date '+%Y-%m-%d %H:%M'):"，方便人工排查
du 统计大目录时容易漏掉隐藏文件和符号链接
想观察某个目录（比如 /var/log）随时间增长的情况，不能只跑一次 du -sh /var/log，得固定参数、固定路径、固定深度反复执行。
典型错误是忽略以下三点：
- 没加
-a或--all时，du默认跳过隐藏文件（以.开头的），而日志轮转常生成.log.swp或.old类临时文件 - 默认会跟随符号链接并统计目标内容，若要只算链接自身大小（比如
/var/log/syslog指向/dev/null），得加-L参数才生效 -
--max-depth=1在不同 GNU coreutils 版本行为不一致：旧版（如 CentOS 7）对根目录/无效，得改用du -sh /* 2>/dev/null
inode 耗尽会导致“空间还有却无法写入”，必须单独监控
当 df -h 显示使用率仅 60%，但程序报 No space left on device，大概率是 inode 不足。这不是空间趋势问题，而是另一维度的资源瓶颈。
查 inode 使用率用：df -i —— 注意看 IUse% 列，不是 Use%
-
/var和/var/spool是 inode 高危区：邮件队列、定时任务输出、容器日志碎片都会快速消耗 inode - ext4 默认每 16KB 分配一个 inode，小文件多的场景（如大量 JSON 日志）极易耗尽
- 监控脚本里别只 grep
Use%，得同时检查IUse%是否 >90%
ncdu 不能直接导出历史数据，但可辅助定位突增源头
ncdu 是交互式分析工具，适合单次深入排查，但它不保存历史、不支持增量扫描、也不输出结构化数据供绘图。
真正有用的操作是：
- 在怀疑时段前后分别运行：
ncdu -o /tmp/ncdu-before.json /var和ncdu -o /tmp/ncdu-after.json /var，再用diff对比 JSON 输出 - 避免直接扫
/：加--exclude排除/proc、/sys、/dev，否则会卡住或报权限错 - 如果服务器内存紧张，启动时加
-x（不跨文件系统）防止误入 NFS 或 CIFS 挂载点，拖慢整个扫描
趋势的本质是“变化”，而变化藏在两次采样之间的差值里。没人能靠单条 df 命令看出趋势——得动手记下来，再比对。最易被忽略的，其实是 df -i 和 du 的参数一致性：同一路径、同一选项、同一时间点，缺一不可。
