在日常运维工作中，Linux 服务器文件系统增长过快是最常见的棘手问题之一。很多时候我们还没反应过来，磁盘使用率就飙到了 90% 以上，导致服务告警甚至应用中断。我处理过上百起这类故障，发现问题的根源往往不是单一的大文件，而是多种因素叠加的结果。下面我从几个核心角度，分享排查和解决这类问题的实战经验。
日志文件轮转缺失
很多服务器磁盘被写满，首当其冲的就是日志文件。特别是应用日志、系统日志和容器日志，如果 logrotate 配置不当或者根本没配置，日志就会无限累积。我曾遇到一个 Tomcat 应用linux 删除文件夹，catalina.out 文件一年没轮转，单文件达到 80GB。检查 /etc/logrotate.conf 和 /etc/logrotate.d/ 下的配置，确认轮转周期、保留份数、压缩选项是否按预期执行。另外要注意linux 文件增长速度，某些应用在日志轮转后没有向进程发送信号重新打开文件句柄，导致旧文件虽被重命名但仍被进程占用，空间无法释放。
数据库文件持续膨胀
数据库的数据文件和 binlog 是另一个隐藏的“吞空间大户”。MySQL 的 ibdata1 文件如果开启了 innodb_file_per_table 但未对共享表空间做限制，可能膨胀到数百 GB。更常见的是二进制日志（binlog）未设置自动清理，或者清理保留天数过长。排查时用 du -sh /var/lib/mysql 快速定位大小，再结合 show binary logs 命令查看 binlog 占用。对于 PostgreSQL，则要留意 WAL 日志堆积，尤其是复制槽处于 inactive 状态时，WAL 会一直保留不被清除，磁盘瞬间就会被撑爆。
容器与镜像存储层
使用 Docker 或 Kubernetes 的环境，文件系统增长常常来自镜像层和容器的可写层。docker overlay2 目录下，停止的容器、未使用的镜像、悬空的卷都会占用大量空间。通过 docker system df 可以查看各级别占用情况，而 docker system prune -a 能一键清理，但生产环境需谨慎linux操作系统原理，避免误删正在使用的镜像。此外，容器内应用产生的日志如果直接写入容器可写层，且未配置日志驱动限制，也会导致宿主机磁盘迅速增长。建议为所有容器配置 json-file 日志驱动的 max-size 和 max-file 参数。
程序内存转储文件
当进程发生崩溃或被手动触发 core dump 时，系统会生成 core 文件用于事后调试。如果 ulimit -c 设置为 unlimited，并且 /proc/sys/kernel/core_pattern 指向了普通目录，一个占用数十 GB 的 core 文件就可能出现。尤其在 Java 或 C++ 应用频繁重启的场景下，多个 core 文件会快速填满磁盘。排查时用 find / -name core.* -type f -size +1G 可以快速定位。解决思路是限制 core 文件大小linux 文件增长速度，或者将 core 文件定向到单独的大容量分区，并配置自动清理脚本。
临时文件与缓存堆积
/tmp 目录和程序运行时生成的临时文件经常被忽略。一些任务调度脚本（如 crontab 或 Jenkins 构建任务）会生成大量临时文件但未做清理。另外，Nginx 的 proxy_temp 目录、yum 的缓存目录、pip 的缓存目录，随着时间推移也会累积到几十 GB。使用 ncdu 或 du -sh 逐一排查这些目录。对于 /tmp 目录，可以考虑挂载为 tmpfs 并限制大小，重启即自动清空；对于各类包管理器的缓存，定期执行 yum clean all 或 apt-get clean 就能有效释放空间。
隐藏的稀疏文件与空洞
有些文件看似体积不大，但实际占用的磁盘块远超预期，这就是稀疏文件或文件空洞造成的。典型场景是虚拟机镜像文件（如 qcow2）或数据库预分配文件。使用 ls -lh 看到的大小是逻辑大小，而 du -sh 看到的是实际占用物理空间。如果两者差异巨大，说明文件存在大量空洞。处理这类问题时，对于虚拟机镜像可以用 qemu-img 进行压缩或转换；对于数据库文件，则需通过重建表或收缩表空间来回收实际磁盘空间。
你的服务器上一次因为磁盘写满导致故障是什么原因？有没有哪种情况排查起来最让你头疼？欢迎在评论区分享你的经历，也记得点赞转发，让更多运维同行少踩坑。
