根分区50G不够用，须按日志、数据库、上传三类写入源分别估算监控；/、/var、/data应物理分离并配合适当文件系统；监控需预测耗尽时间而非仅看阈值；LVM扩容后须依文件系统类型执行对应命令。
别信“根分区给50G够用”这种话
这是最常踩的坑——把业务增长当静态快照。真实场景里，/var/log可能一天涨2GB，/data/pgdata每月翻倍，而/里系统文件三年才变一次。盲目按当前df -h结果乘个系数，等于提前埋雷。真正要盯的是三类写入源：日志路径（查journalctl --disk-usage或du -sh /var/log/nginx/* | sort -hr）、数据库目录（MySQL用SELECT table_schema, SUM(data_length + index_length)，PostgreSQL用pg_size_pretty(pg_database_size('dbname'))）、上传目录（find /opt/app/uploads -type f -mtime -30 | xargs du -ch | tail -1）。它们的增长曲线完全不同，必须分开估算、分开监控。
分区不是为了“整齐”，是为了故障隔离
把/var/log和/塞进同一个分区，等于让SSH登录和Nginx日志共用一张船票——/var/log写满后，systemd-journald崩溃、sshd无法写日志、甚至sudo都失败。关键路径必须物理分离：/只放系统二进制，15–20GB足矣；/var单独挂载，初始40–60GB，并配logrotate压缩+轮转（比如daily + rotate 7 + compress）；/data或/home这类业务数据目录务必独立，且底层用XFS或LVM——否则扩容时发现ext4不支持在线resize2fs，就得停机。
监控不能只看85%，得算“还剩几小时”
df -h告警设在85%？高写入场景下这等于等死。必须叠加时间维度：df --output=avail /data每天凌晨记录一次，取最近7天数据拟合下降斜率，推算耗尽时间（单位：小时）。脚本里写if [ $hours_left -lt 48 ]; then send_alert "less than 2 days"; fi。还要排除干扰项：lsof +L1查被删除但进程仍占句柄的大文件（常见于Java服务未重启），这类空间df看不见，lsof能定位，不处理就永远清不掉。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
LVM不是万能胶，XFS和ext4扩容命令完全不同
很多人以为“LVM逻辑卷扩大了，文件系统就自动跟上”，结果lvextend -l +100%FREE /dev/vg/lv_data执行完，df -h还是老样子。因为：XFS必须用xfs_growfs /data（挂载点路径，不是设备名）；ext4得用resize2fs /dev/vg/lv_data（设备名，不是挂载点）。更坑的是，有些旧镜像默认装ext4却没装e2fsprogs，resize2fs命令直接不存在。上线前务必确认：file -s /dev/vg/lv_data查文件系统类型，which xfs_growfs resize2fs查工具是否就位。
容量规划最难的不是算数字，而是把“业务增长节奏”翻译成df曲线——它要求你定期重估日志保留策略、数据库归档频率、上传文件生命周期，而不是一劳永逸配个阈值。
