磁盘写满是 Linux 运维中最常见的故障之一：服务写不了日志、数据库无法提交、甚至无法通过 SSH 正常登录。本帖按“应急处理 → 根因定位 → 预防”的顺序整理。

一、先确认是哪种“满”
1. df -h 看空间使用率；
2. df -i 看 inode 使用率。大量小文件（如会话文件、缓存碎片）可能在空间还有剩余时耗尽 inode；
3. 如果 df 显示已满，但 du 统计的总量明显偏小，通常是“已删除但仍被进程占用”的文件。

二、快速定位大文件和大目录
1. du -xh --max-depth=1 / | sort -h，逐层向下查找，-x 避免跨文件系统；
2. 常见大户：/var/log、应用日志目录、容器镜像和卷（/var/lib/docker 或 containerd 目录）、核心转储文件、旧的备份包；
3. lsof +L1 列出已删除但仍被打开的文件，这类空间需要重启或通知对应进程重新打开文件才能释放。

三、安全清理
1. 不要直接 rm 正在写入的日志文件，可以先用 truncate -s 0 清空，再处理轮转配置；
2. journald 日志可以用 journalctl --vacuum-size=500M 或 --vacuum-time=7d 控制；
3. 包管理缓存：apt clean、dnf clean all；
4. 容器环境：清理悬空镜像和已停止的容器前，确认没有被其他服务依赖；
5. 数据库文件、WAL/binlog 不要手工删除，应使用数据库自带的清理命令或调整保留策略。

四、预防措施
1. 配置 logrotate：按大小和时间轮转、压缩、限制保留份数；
2. 监控告警分两级，例如 80% 预警、90% 紧急，并对 inode 使用率同样设置告警；
3. 日志、数据、系统分区分开，避免应用日志写满根分区导致系统不可用；
4. 为根文件系统保留一定的预留块（ext4 默认 5%），关键时刻 root 仍可登录处理；
5. 定期检查核心转储设置，生产环境限制 core 文件大小或集中存放。

五、复盘要点
每次磁盘写满后记录：哪个目录、增长速度、为什么监控没有提前发现。很多情况下真正的问题是某个服务日志级别被临时调成 DEBUG 后忘记改回。

欢迎分享你们的磁盘容量规划和告警阈值经验。