# df 说满了，du 加起来却对不上

::: center  
![封面_磁盘排查_博客_336x200_v3_刻度.png](https://developer.qcloudimg.com/http-save/yehe-11546919/8ff18a8e44c4ce72d2e55314fe915408.png)
:::

告警弹出来的时候，我手停在键盘上。

根分区又满了。那台机器上跑着应用中间件、授权服务，还有安全 agent，一个都不能停。

在根分区只有几十个 G 的机器上过日子的人，大概都认得这种感觉。告警一响，手先悬着，脑子里过的全是这上面的东西我碰得起哪一个。

跟上面解释的时候，我一般只说空间不够四个字。对方听到的是该加盘了。我心里过的是这台机器上跑的东西一个都不敢碰，怕清错了当时没崩、第二天才有人来问。后半句不太好说出口，我猜不少同行也这么憋过。

我收藏过不少清理贴，存的时候觉得挺全，真到生产上一翻，清一色是删除命令。压缩 journal、递归删掉某个日志目录、清缓存。一条都不敢直接敲。后来我把顺序改了，先看清再动手。这篇写的就是看清这一步，四层，全是只读命令。

## 动手之前，三条摆在前头

这四层命令一条都不改机器上的东西，输出贴进值班记录，先拿证据再谈怎么腾。

命令里的路径、服务名和水位线按你自己的环境填，我给的是顺序，不给一套通用数值。

`cat /etc/redhat-release` 和 `uname -a` 的输出顺手记进记录，版本号按当时看到的写。下面这台机器是 CentOS 7.4。下次再碰到同类问题，你能对着同一套环境复跑一遍。

三条摆在前头，后面每一步都走得稳。

四层的输出都来自同一台机器，命令里的路径按你自己的环境换。

## 第一层，先看全局水位

从最外面往里走，先认一下机器，免得拿着别台的经验硬套。

```bash
[root@instance2 ~]# cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
[root@instance2 ~]#
```

下面这段是同一台机器上的原样输出。粘贴时行尾的换行被压在一起，我按列还原了，数字一个没动。

```bash
[root@instance2 ~]# df -Th
Filesystem                      Type      Size  Used Avail Use% Mounted on
/dev/mapper/centos_caip122-root ext4       42G   39G  186M 100% /
devtmpfs                        devtmpfs   16G     0   16G   0% /dev
tmpfs                           tmpfs      16G     0   16G   0% /dev/shm
tmpfs                           tmpfs      16G  708K   16G   1% /run
tmpfs                           tmpfs      16G     0   16G   0% /sys/fs/cgroup
/dev/sda2                       ext4      190M   93M   83M  53% /boot
/dev/sdc1                       xfs       100G   60G   41G  60% /redo
/dev/sdb1                       xfs       100G   43G   58G  43% /data
overlay                         overlay    42G   39G  186M 100% /var/lib/docker/overlay2/b747b06ba1630242046db342477a690e1926012484be4b130e38ea3afb1dfb26/merged
overlay                         overlay    42G   39G  186M 100% /var/lib/docker/overlay2/4881b29b8cefa3c9d4b3f75645c72eded196c8990d957bcb2dd765faf70bbdf0/merged
tmpfs                           tmpfs     3.2G     0  3.2G   0% /run/user/0
[root@instance2 ~]#
```

根分区那行就够说明问题。`/dev/mapper/centos_caip122-root` 是 ext4，42G 用了 39G，`Use%` 顶到 100%，`Avail` 只剩 186M。ext4 会给 root 留一部分保留块，所以这两列看着对不上，其实是同一份空间的两种算法。别被那 186M 骗了，普通用户这会儿写文件已经会报没空间。

文件系统类型也在这行里。ext4 还是 xfs，后面查 inode、看碎片、估扩容方式，路子都不一样。

接着往下看挂载点。`/redo` 和 `/data` 各挂一块 100G 的 xfs，分别用了 60% 和 43%。它们是独立文件系统，不占这 42G。这一点待会儿第二层 `du` 的 `-x` 要用上。

还有两行 overlay，数字跟根分区一行不差，42G、39G、186M、100%。容器可写层落在这块盘上，容器里写进去的东西直接吃根分区。后面钻目录的时候，`/var/lib/docker` 这支得单独看一眼。

再数一遍 inode。

```bash
[root@instance2 ~]# df -i
Filesystem                        Inodes   IUsed    IFree IUse% Mounted on
/dev/mapper/centos_caip122-root  2744320 2216288   528032   81% /
devtmpfs                         4113723     411  4113312    1% /dev
tmpfs                            4116441       1  4116440    1% /dev/shm
tmpfs                            4116441     606  4115835    1% /run
tmpfs                            4116441      16  4116425    1% /sys/fs/cgroup
/dev/sda2                          51200     335    50865    1% /boot
/dev/sdc1                       52427776    1126 52426650    1% /redo
/dev/sdb1                       52427776  217314 52210462    1% /data
overlay                          2744320 2216288   528032   81% /var/lib/docker/overlay2/b747b06ba1630242046db342477a690e1926012484be4b130e38ea3afb1dfb26/merged
overlay                          2744320 2216288   528032   81% /var/lib/docker/overlay2/4881b29b8cefa3c9d4b3f75645c72eded196c8990d957bcb2dd765faf70bbdf0/merged
tmpfs                            4116441       1  4116440    1% /run/user/0
[root@instance2 ~]#
```

`IUse% 81%`，`IFree` 还有 528032 个空位。空间满了，名额没满，这台机器可以先排除 inode 用尽这个方向，往下走目录占用。

我留着 `df -i` 是因为另一类故障长这样。空间还有、文件却建不出来，八成要去数 inode。打个比方，仓库里的货位编号发完了，货架上其实还空着一大片，可没编号就放不进去。空间看的是面积，inode 看的是名额，两码事。这次名额够，那个比方先搁着。

这一层看完，你手里该有一句话能说清，是根分区满了，还是根分区上的某个挂载点满了。这台机器是前者，42G 的根满了，两块数据盘另有空间。

## 第二层，根下第一层各占多少

```bash
[root@instance2 ~]# du -xhd1 / 2>/dev/null | sort -h
4.0K    /media
4.0K    /srv
4.0K    /tidb1
8.0K    /nfs
12K     /snap
16K     /lost+found
2.3M    /mnt
22M     /ansible
46M     /etc
190M    /tmp
208M    /soft
383M    /u01
1.7G    /opt
4.0G    /root
4.9G    /usr
8.7G    /home
19G     /var
39G     /
[root@instance2 ~]#
```

`-x` 别省。看上面那段 `df -Th`，`/data` 和 `/redo` 各是 100G 的独立盘。少了 `-x`，`du` 会顺着挂载点钻进去，把那 43G 和 60G 一起算进根下，你会看到一个百 G 级的大目录，以为找着元凶，其实那块盘根本不归这 42G 管。加了 `-x`，最后的汇总行是 39G，跟第一层 `df` 的 Used 一行对得上。

`-d1` 只看第一层，先看是哪一支在涨，再决定往哪支里钻。一上来就全盘扫一遍，小盘机器上这一下自己先吃掉不少 IO。

这份清单里答案挺干脆，`/var` 19G，差不多占了一半，往下 `/home` 8.7G、`/usr` 4.9G、`/root` 4.0G。该往哪钻不用猜了。

往下钻的时候留个习惯，每进一层，把那层的输出贴进值班记录。事后有人问为什么动这个目录，记录比记忆靠谱。候选目录也是这么一层层筛出来的，先有大方向，再有小目录。

## 第三层，那截对不上的空间去哪了

先把话说清楚。这台机器上 `df` 和 `du` 在 G 这一位是对得上的，一个 Used 39G，一个汇总 39G。标题里那句对不上，指的是另一类现场，也是我每次都要单独查这一层的原因。这台机器给我的，是一串 deleted 文件。

```bash
[root@instance2 ~]# lsof +L1 2>/dev/null | head -40
COMMAND    PID          USER   FD   TYPE DEVICE SIZE/OFF NLINK    NODE NAME
rsyslogd   892          root   25r   REG  253,0  8388608     0 1523377 /var/log/journal/b50a2c0ac70f451e892ff1a28c67f121/system@88cbfffedb0d47b28f88c0f3783a6b44-000000000067669c-00065efacd68b16d.journal (deleted)
rsyslogd   892          root  181r   REG  253,0  8388608     0 1478014 /var/log/journal/b50a2c0ac70f451e892ff1a28c67f121/user-1003@d47ddcf5a040489caa8c232b068ed5a9-0000000000675287-00065efa0c1c9df4.journal (deleted)
filebeat  1371          root   28r   REG  253,0 28248954     0  292368 /var/log/elasticsearch/Es-Cluster-one-2026-11-05-1.log (deleted)
filebeat  1371          root   31r   REG  253,0 40364788     0  268783 /var/log/elasticsearch/Es-Cluster-one-2026-11-05-1.json (deleted)
filebeat  1371          root   49r   REG  253,0 32995356     0  270112 /var/log/elasticsearch/Es-Cluster-one-2026-11-06-1.log (deleted)
java      1375 elasticsearch    0r   REG  253,0        1     0 1835058 /tmp/sh-thd-1793822840 (deleted)
java      1375 elasticsearch   54u   REG  253,0     4096     0 1835066 /tmp/E9Vk72 (deleted)
java      1375 elasticsearch  286r  FIFO  253,0      0t0     0 1835067 /tmp/elasticsearch-3874696340319736460/controller_log_1375 (deleted)
java      1375 elasticsearch  287w  FIFO  253,0      0t0     0 1835068 /tmp/elasticsearch-3874696340319736460/controller_command_1375 (deleted)
java      1375 elasticsearch  288r  FIFO  253,0      0t0     0 1835069 /tmp/elasticsearch-3874696340319736460/controller_output_1375 (deleted)
mysqld    2325       polkitd    4u   REG  253,0        0     0 1477934 /tmp/ibDGXbXt (deleted)
mysqld    2325       polkitd    5u   REG  253,0        0     0 1523223 /tmp/ibuu3DMl (deleted)
mysqld    2325       polkitd    6u   REG  253,0        0     0 1523236 /tmp/ibBYWmxt (deleted)
mysqld    2325       polkitd   11u   REG  253,0        0     0 1523239 /tmp/ibm3SAH6 (deleted)
controlle 2652 elasticsearch    2w  FIFO  253,0      0t0     0 1835067 /tmp/elasticsearch-3874696340319736460/controller_log_1375 (deleted)
controlle 2652 elasticsearch    3w  FIFO  253,0      0t0     0 1835067 /tmp/elasticsearch-3874696340319736460/controller_log_1375 (deleted)
controlle 2652 elasticsearch    5r  FIFO  253,0      0t0     0 1835068 /tmp/elasticsearch-3874696340319736460/controller_command_1375 (deleted)
controlle 2652 elasticsearch    6w  FIFO  253,0      0t0     0 1835069 /tmp/elasticsearch-3874696340319736460/controller_output_1375 (deleted)
[root@instance2 ~]#
```

`NLINK` 那列全是 0，NAME 末尾都挂着 `(deleted)`。文件已经从目录里摘掉了，可还有进程开着它，句柄没松，文件系统就不把这部分空间还回来。

占空间的是 `TYPE REG` 那几行，`FIFO` 那几行的 `SIZE/OFF` 是 `0t0`，不占块，别被行数吓着。把 REG 那几行按字节加起来，一百多 MB，被 39G 这个整数盖得严严实实。换台机器，删掉的若是几个大文件，差额就会从 MB 跳到 G，那时候标题里那句才整个显形。

像图书馆把书从架上下架了，可还有人捧着在读，书架就不算腾空。你想让书架空出来，得等那位读者把书合上，光在书架前头找是找不到的。

看到这些条目，要动的对象已经从文件变成了那个进程。日志服务、日志采集、搜索服务、数据库，各自的进程能不能重启、重启会不会把正在跑的业务带下去，得一条条看。这块我没法给一张通用表，每台机器上跑的服务、依赖关系、日志轮转配置都不一样，同一条命令的输出，在两台机器上可能指向两个完全不同的动作。

第四层那两组数字正好接得上。攥着 deleted 文件的这几个进程，写的就是 journal 和搜索服务日志那两支目录。轮转把文件从目录里摘掉了，句柄还开着，空间就一直挂着。

## 第四层，日志这块单独看

第二层那个 19G 的 `/var`，往下钻就是这里。

```bash
[root@instance2 ~]# journalctl --disk-usage
Archived and active journals take up 4.0G on disk.
[root@instance2 ~]# du -xhd1 /var/log 2>/dev/null | sort -h
4.0K    /var/log/chrony
4.0K    /var/log/kibana
4.0K    /var/log/ntpstats
4.0K    /var/log/rhsm
84K     /var/log/tuned
472K    /var/log/containers
2.6M    /var/log/anaconda
36M     /var/log/sa
40M     /var/log/audit
51M     /var/log/vmware-caf
347M    /var/log/mongodb
796M    /var/log/elasticsearch
4.1G    /var/log/journal
5.8G    /var/log
[root@instance2 ~]#
```

`journalctl --disk-usage` 报 4.0G，`du` 数出来的 `/var/log/journal` 是 4.1G。一个按归档加活动算，一个按目录占的块算，差这一小截属正常，别当成两个数打架。

`/var/log` 5.8G 里，journal 占 4.1G，后面跟着搜索服务日志 796M 和数据库日志 347M。第三层那几个 deleted 文件，路径就落在这两支目录里。日志轮转把旧文件摘走，采集进程还攥着句柄，于是目录里看着清掉了，盘上的水位没动。这条链子四层跑完才对得上。

还有一笔要记着，`/var` 是 19G，日志只占 5.8G。剩下的往 `/var/lib/docker` 那支钻，第一层那两行 overlay 已经把方向指出来了。

`journalctl --disk-usage` 只报数，不动文件。它和目录里的日志是两笔账，一笔归 journald 管，一笔归各个服务自己的日志文件管。混在一起看，容易把同一份占用算两遍。

到这一层，谁在涨、从哪天开始涨、涨的是轮转产物还是某个服务一直在写，基本能对上号。对不上就别急着往下走，回到第二层再钻一层，多半有支目录刚才被 `sort -h` 挤到了后面。

## 真要动手之前

看清之后才轮到清理，这一步我给自己留了几条硬规矩。

候选目录先列出来，贴给值班的人逐条过。这台机器上候选已经很清楚，journal 4.1G、搜索服务日志 796M，加上第三层那几个攥着 deleted 文件的进程。谁占多少、从哪天开始涨的、清了会不会影响正在写的日志，一条条确认完再动手。别用一条命令把一整层带走，那玩意儿敲下去连回看的机会都没有。

删除命令粘贴之前多看一眼。我从聊天记录里复制命令，不止一次把行尾那个 `$` 一起带进去，`find` 当场给我报了错，算是运气好。提示符跟命令是两回事，写进记录里比记在脑子里管用。

还有个容易漏的，重启服务释放句柄之前，先确认这个服务重不重启得起、有没有依赖它的东西。释放空间把业务带停了，这笔账划不来。

清理完别急着关工单。过一阵子回头看一次水位，涨回来的速度比清出来多少更能说明问题。慢涨的找配置，隔天就满的找进程，这两件事的解法差得远。

## 空间到底怎么回来

看清之后，这台机器上要动的地方，跟收藏夹里那些清理贴写的不一样。

轮转早把文件从目录里摘走了，`NLINK` 全是 0。目录里已经找不到它们，再敲一遍删除命令也够不着，盘上那一截挂在进程的句柄上。让水位下来的动作，是让攥着它们的那几个进程把句柄松开。日志服务、采集进程、搜索服务，挑维护窗口一个一个来，每动一个回头看一次，别一次全推倒。

复看只用两条只读命令。

```bash
[root@instance2 ~]# lsof +L1 2>/dev/null | head -20
[root@instance2 ~]# df -hT /
```

第一条看 `(deleted)` 那批还在不在，第二条看水位掉没掉。两个都没变，句柄就还在别处，回到第三层按 PID 再找一遍。

journal 那 4.1G 是另一笔账。它归 journald 自己的配额和轮转策略管，目录里删文件动不到它，配置改完还得让服务重新读一次才生效。动之前先看这台机器上当前写的是多少，别照着别的机器抄。

`/var` 19G 里剩下那截往容器可写层钻，第一层那两行 overlay 指的就是它。镜像层、容器日志、临时卷各占多少得按自己环境核，跟日志这支分开算。

这篇给到判据就收住，谁能重启、什么时候重启、动完拿什么验证。同一串输出换台机器，答案可能整个翻过来，塞一张通用命令表进去反而害人。至于上面这些动作各自跑完是什么结果，这台机器上我没做过一轮完整记录，没跑过的数不往纸上写。

## 临走前带走的三条

四层从外往里走，这台机器上 `/var` 19G 是大头，钻到 `/var/log` 5.8G，再钻到 journal 4.1G，每层输出都留证据。

`df` 和 `du` 在 G 这一位对得上，不代表没有未释放的句柄。`lsof +L1` 要单独查一层，差额可能只藏在字节级。

日志轮转删了文件，空间不一定回来。攥着 deleted 文件的进程才是要动的对象，哪个能重启得一条条看。

写到这里，该动哪几处已经点出来了，动不动、什么时候动，还得看那台机器上跑着什么。

磁盘告警响的时候，你第一件事是敲 `df`，还是先翻日志目录？

---

**关于作者**

数据库界华少（shunwah），常驻杭州，资深 DBA，长期深耕国产分布式数据库与 Data+AI 智能运维。解锁 OceanBase、MySQL、OpenGauss、金仓、崖山、KaiwuDB、TiDB 等十几家数据库官方认证。

**社区身份**：OpenTenBase ACE ｜ OceanBase 社区版主 ｜ 墨天轮 MVP ｜ 崖山 YVP ｜ KaiwuDB MVP ｜ 金仓 KVA ｜ TiDB MVA ｜ NebulaGraph 伙伴 ｜ IFClub 专家 ｜ GBase 8a ｜ ITPUB 专家

**腾讯云相关**：腾讯云架构师上海同盟成员 ｜ 腾讯云开发者先锋 TDP ｜ 腾讯云创作之星 ｜ 腾讯云合作讲师

**公众号**：shunwah 星辰数智社

⚡ 不是在测数据库，就是在去测数据库的路上。

*原创内容 · 转载请联系授权*


根分区又满了。那台机器上跑着应用中间件、授权服务，还有安全 agent，一个都不能停。

磁盘 df 说满了，du 加起来却对不上

42G 的根分区亮了 100%，上面跑着好几个不能停的服务。这篇没给一条删除命令，只用四层只读命令把 39G 拆开，钻到 journal 的 4.1G。最后卡在一个地方，日志轮转把文件删了，进程还攥着句柄，空间没回来。

运维工程师

架构设计

Linux根分区爆满时，用df和du排查空间差异，通过lsof检查被删除但未释放的句柄文件，journalctl查看日志占用，安全定位空间去向，避免误删生产文件。

分布式数据库

Elasticsearch 

日志文件

代码解释

文件系统

日志服务

云架构

数据库

中间件

Docker

容器

MySQL

Agent

JSON

让每一个 Agent，都跑在云上

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

磁盘 df 说满了，du 加起来却对不上-腾讯云开发者社区-腾讯云

磁盘 df 说满了，du 加起来却对不上

磁盘 df 说满了，du 加起来却对不上

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐