「磁盘满了」和「内存不够」是两件事，处理顺序也不一样。df 报满，说明某个文件系统的块或 inode 被用尽；free 显示内存高，说明 RAM 里数据多。清理内存通常不会让 df 的占用变小，唯一例外是占用落在 tmpfs 上（/dev/shm、/run，部分发行版的 /tmp 默认就是 tmpfs），这类“磁盘”实际是内存，两边会一起涨。所以先分清是哪一层，再动手删，比直接找大文件删要稳。
先在服务器上执行df -hT和df -i：前者看哪个分区、什么类型满了，后者看是不是 inode 耗尽而不是空间不足。两个输出都正常却仍报错时，再查被删除但仍被进程占用的文件（lsof +L1）。tmpfs 占满属于内存问题，需要缩小内存盘或迁移写入目录，不是删磁盘文件。清理动作用 truncate 和轮转配置替代直接 rm，避免删了文件空间不释放。
Linux系统磁盘满先定位在哪一层
排查时先在脑子里过一层归属：问题可能出在应用写入、文件系统、存储映射或内存盘。层级判断错了，往往一边删文件一边看着 df 不动，反复几轮也解决不了。
- 应用写入层：日志、上传目录、临时文件、缓存目录在持续增长。判断依据是
du -x -h --max-depth=1 /显示某个业务目录占用突出，且与最近上线、报错量或访问量变化时间吻合。 - 文件系统层：
df -hT显示某个挂载点 Use% 接近 100%；df -i显示 IUse% 接近 100% 则是小文件太多把 inode 用完了，症状一样但处理完全不同。 - 存储映射层：
df显示的容量小于lsblk看到的块设备容量，说明扩容后没有扩展文件系统；LVM thin pool、云盘快照挂载等也要在这一层对照。 - 内存层：
df -hT的输出里出现 tmpfs 类型且占用高，free -h的 shared 同步偏高。这一层清理的是写入 tmpfs 的进程产物，不是“清理内存缓存”。
Linux系统磁盘满：先看这四个位置
下面四条按顺序执行，基本能在几分钟内把范围缩小到一个目录。命令都在目标主机上以 root 或有 sudo 权限的账号运行。
1. 日志目录与 journal：先看 /var/log 里谁最大，再看 journald 自己占了多少。
du -x -h --max-depth=1 /var/log 2>/dev/null | sort -h | tail -n 10
ls -lSh /var/log | head -n 10
journalctl --disk-usage2. 命令输出里的两个关键数字：df -hT 确定是哪个挂载点，df -i 确认是不是 inode 问题，再向下钻一层目录。
df -hT
df -i
du -x -h --max-depth=1 / 2>/dev/null | sort -h | tail -n 153. 轮转与日志上限配置：占用反复回来的根因常在这里。需要对照的文件是 /etc/logrotate.conf、/etc/logrotate.d/ 下的业务配置（看 rotate、size、maxsize、daily）、/etc/systemd/journald.conf 的 SystemMaxUse、/etc/docker/daemon.json 的 log-opts 是否设置了 max-size。这些字段的具体默认值随发行版和容器运行时版本不同，以本机文件内容和对应版本的 man logrotate.conf、man journald.conf、man docker-daemon 为准。
4. 面板与监控字段：云主机控制台的云盘监控页看“磁盘使用率”，部分实例还提供 inode 使用率指标；容器面板看 /var/lib/docker 所在分区和容器可写层占用；自建监控看 df 采集项的文件系统维度，不要只看整机一个汇总值。面板数值有采集间隔，判断以本机命令输出为准，面板用于看趋势。
Linux系统磁盘满：按可能性从高到低排除
下面按实际遇到频率排序，每条都给出确认动作。确认排除后再看下一条，不要跳着改。
- 日志暴涨（最常见）。确认：
du -x -h --max-depth=2 /var/log | sort -h | tail，再tail -n 50看该文件是否在刷同一条错误。处理：truncate -s 0 /var/log/xxx.log先释放空间，再查应用为什么刷日志并调整/etc/logrotate.d/对应配置。 - 已删除但被进程持有的文件。确认：
lsof +L1 2>/dev/null | head -n 20。处理：重启或 reload 持有该文件的进程，空间才会真正归还；直接 rm 无效。 - 容器镜像与容器日志。确认：
docker system df，再du -x -h --max-depth=1 /var/lib/docker。处理：清理停止的容器和悬空镜像（docker image prune），并给 daemon.json 加上日志大小上限。 - 业务目录堆积：上传、备份、导出、临时目录。确认：
du -x -h --max-depth=1 /data 2>/dev/null | sort -h | tail，按修改时间抽查find /data -type f -mtime +30 | head。处理：按保留策略删除或转存，删除前确认无进程或下游依赖。 - inode 耗尽。确认：
df -i的 IUse% 接近 100%。处理：找小文件密集目录ls -U /path | head，清理会话文件、缓存碎片、队列残留；单纯删大文件对 inode 无用。 - tmpfs 占满内存。确认：
df -hT | grep tmpfs与free -h同步偏高。处理：把写入/dev/shm或/tmp的进程产物迁到磁盘分区，必要时调小 tmpfs 大小；这不是“清理内存缓存”能解决的问题。
一个容易踩的坑：用 rm 删掉正在写入的大日志后，df 依然显示满，因为进程还持有文件句柄。对正在写的日志用 truncate -s 0；已经 rm 掉的，必须让持有进程重新打开文件，空间才回收。drop_caches 只在极少数场景作为临时缓解，不解决磁盘写入问题，也不该当作常规手段。
Linux系统磁盘满：改完怎么确认真的解决了
清理完先做一次即时核对，再观察一个完整周期。df -hT 和 df -i 的 Use% 应回落到预期区间；lsof +L1 无输出说明没有残留的已删除文件；journalctl --disk-usage 与清理前的记录对比。观察时长建议覆盖一个日志轮转周期或一个业务高峰周期（通常一天），期间不出现新的告警才算稳定。
df -hT
df -i
lsof +L1 2>/dev/null | wc -l
journalctl --disk-usage回滚要提前准备好，尤其是动过配置的情况。修改 /etc/logrotate.d/ 或 /etc/systemd/journald.conf 前，先 cp /etc/logrotate.d/xxx /etc/logrotate.d/xxx.bak 备份，出问题用 mv 还原。journald 的 vacuum 操作本身不可逆，所以优先改 SystemMaxUse 让它自行轮转，而不是一次性清空。删除或清理数据目录前，先记录一份文件清单（find /data -type f -size +100M -exec ls -lh {} \; 输出重定向到临时文件），确认误删时至少能定位原始路径和大小。tmpfs 调小或改挂载参数需要改 /etc/fstab，改动后先 mount -a 验证语法，再择机重启生效。