根分区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能定位，不处理就永远清不掉。
