Inode on Zero Day Notes

Docker 宿主机 overlay2 inode 耗尽致容器批量创建失败的定位

Tue, 07 Jul 2026 12:38:41 +0000

一、问题背景

公司内部的 CI/CD 构建节点是一台 2C4G 的云主机，上面跑着 GitLab Runner，所有流水线任务都通过 docker run 临时拉起容器执行编译、单元测试和镜像打包。这台机器已经稳定运行了半年多，运维也基本是"放养"状态——除了偶尔手动清理一下磁盘，没人专门维护。某天上午，开发同学突然在群里反馈：多条流水线同时失败，报错信息五花八门，有的说"无法拉取镜像"，有的说"容器启动超时"。我登录上去一看，连 docker ps 都开始变得卡顿，这才意识到事情没那么简单。

二、故障现象

最直观的现象是：几乎所有新建容器的操作都会失败。无论是 Runner 自动拉起的构建容器，还是我手动执行的 docker run hello-world，都返回一个类似的错误：

`1`	`docker: Error response from daemon: mkdir /var/lib/docker/overlay2/xxxxxxx: no space left on device.`

更诡异的是，报错明明说 “no space left on device（设备上没有剩余空间）"，但 df -h / 显示的磁盘使用率只有 63%，还有大把空间。开发同学一度怀疑是 Docker 引擎抽风，甚至有人建议直接重启机器"试试看”。

此外，已有的运行中容器并没有崩溃，业务服务照常对外提供访问，只是任何"新建/重启容器"的动作全部失败；docker images 列表里堆积了上百个 <none> 的中间镜像，磁盘肉眼可见地越来越慢。

三、排查过程

第一步，我本能地按"磁盘满"的思路去查。执行 df -h：

1
2

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        50G   32G   18G  63% /

空间明明还剩 18G，所以 “no space left on device” 在这里是假象。结合经验，Linux 上除了字节数，还有另一个隐藏上限——inode 数量。一个文件系统能创建的文件总数受 inode 限制，即使字节没满，inode 耗尽同样会报这个错。

第二步，用 df -i 验证猜测：

1
2

Filesystem       Inodes   IUsed    IFree IUse% Mounted on
/dev/vda1       3276800 3276790       10  100% /

果然，inode 使用率 100%，只剩 10 个可用。问题定性了：这是 inode 耗尽，不是磁盘空间耗尽。

第三步，定位是哪个目录吃掉了 inode。因为 Docker 的根目录默认在 /var/lib/docker，我写了个循环统计子目录的文件数：

1
2
3

for d in /var/lib/docker/*; do
  echo "$d: $(find "$d" -xdev -type f 2>/dev/null | wc -l)"
done

输出显示 /var/lib/docker/overlay2 一个目录就占了 320 多万个文件，几乎吃光了全部 inode。overlay2 是 Docker 的存储驱动，每一层镜像、每个容器的可写层都被拆成一个个真实的小文件存放在这里。

第四步，进一步分析 overlay2 内部构成。用 docker system df 看到：

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          214       12        28.4GB    26.1GB (91%)
Containers      187       3         1.2GB     1.1GB (95%)
Local Volumes   9         2         0         0
Build Cache     0         0         0         0

镜像和"僵尸容器"（已退出但未删除）数量惊人。再钻进 overlay2 看单目录文件数分布，发现大量 <hash>/diff 目录每个都装着几万甚至十几万个小文件——这正是那些 Java/Maven 项目在构建时往容器可写层写入海量 .class、依赖 jar、源码文件留下的痕迹。

第五步，确认加剧因素——日志。检查 /etc/docker/daemon.json，发现根本没有配置 json-file 的日志轮转（max-size / max-file）。这意味着每个容器的标准输出日志都在 /var/lib/docker/containers/<id>/<id>-json.log 里无限增长，虽然单个日志是"大文件"对 inode 贡献不大，但叠加海量中间层小文件，最终把 inode 彻底打满。

至此根因链条清晰：长期不清理 + 构建任务频繁创建容器/镜像 + 日志不轮转，导致 overlay2 累积了数百万个小文件，耗尽 inode，新容器再也无法创建目录。

四、解决方案

当务之急是腾出 inode，让 Docker 能继续工作：

清理已退出容器与悬空镜像（释放海量小文件）：
1 2 3

docker container prune -f docker image prune -a -f docker system prune -a --volumes -f
执行后 df -i 的 IFree 从 10 回升到 290 多万，inode 使用率降到 12%。
重启 Docker 守护进程让状态归一：
1

systemctl restart docker
临时把 Docker 根目录迁到 inode 更充裕的磁盘（可选，针对根盘 inode 本就偏小的云主机）：挂载一块数据盘，修改 daemon.json 的 "data-root": "/data/docker" 后重启。
验证：手动 docker run --rm hello-world 成功，Runner 流水线逐步恢复正常。

五、根因分析

表面看是"磁盘满了"，本质是文件系统 inode 资源被海量小文件耗尽。overlay2 存储驱动把每个镜像层和容器可写层都映射成宿主机的真实文件，构建型任务（编译、打包）会在容器内产生大量细小文件，这些文件在容器退出后若不被清理，就以"僵尸容器 + dangling 镜像"的形式永久占用 inode。再加上日志未配置轮转，雪上加霜。云主机默认文件系统的 inode 总数往往偏小（本例仅 327 万），在 CI 场景下极容易被打满。

六、预防措施

配置日志轮转：在 daemon.json 中加入

1
2

"log-driver": "json-file",
"log-opts": { "max-size": "100m", "max-file": "3" }

建立定期清理机制：用 cron 每天凌晨执行 docker system prune -a -f --filter "until=72h"，只保留近三天的资源。
inode 监控告警：把 df -i 接入监控（Node Exporter + Prometheus 或云监控），inode 使用率超 80% 即告警，比磁盘空间告警更早发现隐患。
构建阶段减少可写层文件：CI 中尽量用多阶段构建（multi-stage build），把编译产生的中间文件留在构建阶段、不带入最终镜像；构建缓存挂载到宿主机独立大目录而非容器可写层。
给 Docker 分配独立数据盘：新建大 inode 文件系统（mkfs.ext4 -i 8192 调高密度）专供 /var/lib/docker，从容量上根除风险。

七、总结

这次故障给我最深的教训是：排查 “no space left on device” 不能只看 df -h，一定要补一眼 df -i。在容器、CI、日志这类"产生海量小文件"的场景里，inode 耗尽比磁盘字节耗尽更常见、更隐蔽。把日志轮转、定期 prune、inode 监控三件事做成标准动作，基本可以杜绝这类问题再次发生。

磁盘有空间却写不进文件？Linux inode 耗尽的坑

Sat, 27 Jun 2026 06:55:00 +0000

一、问题背景

周三上午10点左右，公司核心交易系统的Web层突然开始大量报错。监控平台连续发出"应用日志写入失败"和"业务健康检查超时"的告警，短短5分钟内收到的告警从0飙升至47条。

受影响的是部署在阿里云ECS上的Spring Boot交易网关服务，共3个节点，运行在CentOS 7.9系统上。该服务负责接收前端交易请求并将处理日志写入本地文件，再由Filebeat采集发送到ELK。因日志写入失败，服务开始返回HTTP 500错误，交易成功率从99.8%骤降至73%。

前一天运维同事刚做过一次应用版本发布，第一反应是"新版本有bug"。但在回滚到上一版本后问题依旧，才意识到这很可能不是代码问题，而是基础设施层面的故障。

二、故障现象

登录问题节点后，首先检查应用日志：

$ tail -f /var/log/trade-gateway/application.log
2026-06-27 10:03:42.127 ERROR [pool-3-thread-7] c.t.g.service.OrderService - Failed to write operation log
java.io.IOException: No space left on device
    at java.base/java.io.FileOutputStream.writeBytes(Native Method)
    at java.base/java.io.FileOutputStream.write(FileOutputStream.java:354)
    at java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81)
    ...

“No space left on device”——这个报错非常明确：磁盘没空间了。

习惯性地先查磁盘空间：

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        80G   45G   31G  60%  /
devtmpfs        7.8G     0  7.8G   0%  /dev
tmpfs           7.8G   16K  7.8G   1%  /dev/shm
tmpfs           7.8G  1.2M  7.8G   1%  /run

看得我一愣——根分区总共80G，使用了45G，还有31G可用空间。磁盘并没有满。

不信邪，手动创建文件试试：

$ touch /tmp/test_write
touch: cannot touch '/tmp/test_write': No space left on device

$ echo "test" > /var/log/test.log
-bash: /var/log/test.log: No space left on device

磁盘明明有31GB空闲，却无法创建任何文件。这就是典型的"文不对题"——报错说没空间，df却说空间充裕。此时心里已经有了方向：大概率是inode耗尽了。

三、排查过程

3.1 确认inode使用情况

遇到"磁盘有空间但无法创建文件"，第一个要检查的就是inode：

$ df -i
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda1     5242880 5242880      0  100%  /
devtmpfs      2039552    407 2039145    1%  /dev
tmpfs         2041888     19 2041869    1%  /dev/shm
tmpfs         2041888    833 2041055    1%  /run

真相大白。根分区一共5242880个inode，全部耗尽，IUse% = 100%。文件系统已经没有可用的inode来创建新文件了，哪怕磁盘物理空间还有大量剩余。

3.2 定位inode消耗大户

接下来的任务是找出哪些目录消耗了大量inode。先对整个根目录做一级统计：

$ for dir in /*; do
    if [ -d "$dir" ]; then
        count=$(find "$dir" -xdev -printf '.' | wc -c)
        echo "$count  $dir"
    fi
done | sort -rn | head -10

4892012  /tmp
247163   /var
89321    /usr
31002    /opt
...

接近490万个inode集中在/tmp目录下，几乎占了全部inode的93%。这个发现让排查目标变得非常明确。

3.3 深入/tmp目录分析

进入/tmp目录，用ls看看情况：

1
2

$ cd /tmp && ls | wc -l
4850000

四百八十五万个文件！这个数字令人震惊。进一步查看文件类型分布：

$ ls -lh /tmp | head -20
-rw-r--r-- 1 appuser appuser    0 Jun 24 03:00 .trade_lock_20260624_030001_8372
-rw-r--r-- 1 appuser appuser    0 Jun 24 03:00 .trade_lock_20260624_030002_9104
-rw-r--r-- 1 appuser appuser    0 Jun 24 03:00 .trade_lock_20260624_030003_2841
...
-rw-r--r-- 1 appuser appuser    0 Jun 27 10:00 .trade_lock_20260627_100001_5539

全是以.trade_lock_开头的隐藏文件，大小全部为0字节。这些是应用用于进程互斥的锁文件。

查看文件的创建时间分布：

$ find /tmp -name '.trade_lock_*' -printf '%TY-%Tm-%Td\n' | sort | uniq -c | sort -rn
1520000 2026-06-25
1438000 2026-06-24
1087000 2026-06-26
 696000 2026-06-23
 104000 2026-06-22
...

这批锁文件从6月22日开始累积，最近3天每天产生超过100万个。但关键问题是：为什么这些临时锁文件没有被清理？

3.4 追查清理机制

查了一下项目内部的定时任务和代码逻辑：

1
2
3

$ crontab -l -u appuser
# 每天凌晨3点清理/tmp下超过24小时的临时文件
0 3 * * * find /tmp -name '.trade_lock_*' -mtime +1 -delete

crontab里有一条清理任务：每天凌晨3点删除/tmp下24小时以前的锁文件。逻辑看起来没问题。

手动验证清理逻辑：

1
2

$ find /tmp -name '.trade_lock_*' -mtime +1 | wc -l
4870000

这个结果非常奇怪——几乎全部文件都满足"-mtime +1"条件，说明它们超过24小时了，但cron任务却没能清理掉它们。

继续深挖，查看cron的执行日志：

1
2

$ grep "find /tmp" /var/log/cron | tail -5
Jun 27 03:00:01 trade-gw-01 CROND[19238]: (appuser) CMD (find /tmp -name '.trade_lock_*' -mtime +1 -delete)

cron确实按时执行了。那为什么没删掉？把命令抄出来单独跑一下：

1
2

$ find /tmp -name '.trade_lock_*' -mtime +1 -delete
-bash: /usr/bin/find: Argument list too long

破案了！“Argument list too long”——find命令在内部处理-delete操作时，对于数百万级别的文件，exec的参数列表超出了系统限制。

补充说明：find 的 -delete 参数会尝试在内部批量调用 unlink()，当匹配到的文件数量极其庞大时，仍然可能触发内核的 ARG_MAX 限制（可以通过 getconf ARG_MAX 查看，通常为2MB）。这个限制不仅影响 -exec ... {} \+ 的显式调用，在文件基数达到百万级时也可能影响 -delete。

3.5 定位cron失败的根本原因

进一步验证：

$ getconf ARG_MAX
2097152

$ find /tmp -name '.trade_lock_*' -mtime +1 | wc -c
195482103

所有过期文件路径的总长度约186MB，远超ARG_MAX的2MB限制。find命令在执行-delete时一次性匹配的文件太多，路径总长度超过了内核参数上限，导致删除操作完全失败。

这也解释了为什么故障出现在周三——锁文件从上周日开始累积，到了周三总量突破500万，find -delete彻底失效形成"死锁"：cron定时删→delete失败→文件继续累积→下一次cron更不可能成功→恶性循环，直到inode彻底耗尽。

四、解决方案

4.1 紧急止血

当务之急是让服务恢复。不能直接用rm -rf /tmp/*——/tmp下还有其他进程的运行时文件。需要精准批量删除：

1
2

# 用find配合xargs分批删除，避免ARG_MAX限制
$ find /tmp -name '.trade_lock_*' -mtime +1 -print0 | xargs -0 -n 1000 rm -f

执行过程中持续监控inode恢复情况：

`1`	`$ watch -n 2 'df -i / \| tail -1'`

删除持续了约12分钟，inode使用率从100%降至8%。服务随即恢复正常。

4.2 修复清理机制

原有的cron删除命令需要改造，核心思路是让find通过管道将文件列表传给xargs分批处理，彻底绕过ARG_MAX限制：

修改crontab：

1
2
3

# 将原来的单条find -delete
# 改为 find + xargs 分批删除模式
$ crontab -e -u appuser

1
2

# 每天凌晨3点清理/tmp下超过24小时的锁文件（xargs分批避免ARG_MAX）
0 3 * * * find /tmp -name '.trade_lock_*' -mtime +1 -print0 | xargs -0 -n 500 rm -f

4.3 调整inode监控

在Prometheus中添加inode监控告警规则：

groups:
  - name: filesystem_alerts
    rules:
      - alert: InodeUsageHigh
        expr: (node_filesystem_files_free / node_filesystem_files) * 100 < 10
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "文件系统inode使用率超过90%"
          description: "主机 {{ $labels.instance }} 上 {{ $labels.mountpoint }} 的inode使用率为 {{ $value | humanize }}%，仅剩 {{ $value }}% 可用。"
      
      - alert: InodeUsageCritical
        expr: (node_filesystem_files_free / node_filesystem_files) * 100 < 5
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "文件系统inode使用率超过95%，即将耗尽！"
          description: "主机 {{ $labels.instance }} 上 {{ $labels.mountpoint }} 的inode仅剩 {{ $value }}%，请立即处理。"

同时配置Node Exporter采集inode指标，确保node_filesystem_files和node_filesystem_files_free指标正常上报。

五、根因分析

这个问题的根本原因有三层：

第一层（直接原因）：应用代码使用File.createTempFile()创建的锁文件没有在进程退出时正确清理。代码中虽然注册了deleteOnExit()，但当进程被kill -9强制终止时，JVM的shutdown hook不会执行，锁文件被遗留在磁盘上。

第二层（放大因素）：cron清理脚本使用find -delete一次性处理百万级文件时触发了ARG_MAX限制，导致清理完全失效。一旦清理失败一次，后续每次cron执行都面临更多的文件，形成"越积越多、越积越难清"的死循环。

第三层（监控缺失）：监控体系中只覆盖了磁盘空间（df -h），从未关注inode使用率（df -i）。运维团队直到故障发生才意识到inode是一个独立的资源维度。

六、预防措施

6.1 应用层面

将锁文件从/tmp迁移到应用专属的工作目录，并在应用启动脚本中增加自清理逻辑：

# 在应用启动前清理过期锁文件（配合xargs分批处理）
cleanup_locks() {
    local LOCK_DIR="/data/app/trade-gateway/locks"
    local MAX_AGE_MINUTES=60
    find "$LOCK_DIR" -name '.trade_lock_*' -mmin "+${MAX_AGE_MINUTES}" -print0 \
        | xargs -0 -n 500 rm -f 2>/dev/null
}

同时修改Java代码，使用try-finally确保锁文件在finally块中释放，搭配FileLock机制代替纯文件存在性判断做互斥。

6.2 操作系统层面

调整/tmp的挂载参数，限制inode使用上限：

1
2

# /etc/fstab 中为 /tmp 增加nr_inodes限制
tmpfs /tmp tmpfs defaults,size=4G,nr_inodes=500000 0 0

另外，如果业务允许，可以将频繁产生小文件的目录单独分区并分配更多inode：

1
2

# 创建文件系统时指定更多inode（默认情况下每16KB分配1个inode）
mkfs.ext4 -i 4096 /dev/vdb1  # 每4KB分配1个inode，inode数量变为默认的4倍

6.3 监控层面

强制要求所有生产服务器部署inode监控告警，与磁盘空间监控同等对待。告警阈值：inode使用率 > 80% 预警，> 90% 严重告警，> 95% 紧急告警。

同时建立巡检制度，每周检查一次所有生产服务器的inode使用趋势，提前发现异常增长：

# 巡检脚本示例
for host in $(cat /etc/ansible/hosts | grep '\[prod\]' -A 100 | grep -v '\['); do
    echo "=== $host ==="
    ssh $host "df -i / /data 2>/dev/null | grep -v '^Filesystem'"
done

6.4 清理工具加固

将cron清理脚本统一升级为带有结果校验的版本：

#!/bin/bash
# /usr/local/bin/cleanup_tmp_locks.sh
LOCK_DIR="/tmp"
PATTERN=".trade_lock_*"
MAX_AGE="+1"
BATCH_SIZE=500
ERROR_LOG="/var/log/tmp_cleanup_error.log"

# 分批删除
DELETED=0
while IFS= read -r -d '' file; do
    rm -f "$file" && ((DELETED++))
done < <(find "$LOCK_DIR" -name "$PATTERN" -mtime "$MAX_AGE" -print0 2>/dev/null)

# 结果校验
REMAINING=$(find "$LOCK_DIR" -name "$PATTERN" -mtime "$MAX_AGE" 2>/dev/null | wc -l)

if [ "$REMAINING" -gt 0 ]; then
    echo "$(date): 清理不完整！已删除 $DELETED 个文件，仍有 $REMAINING 个过期文件未清理。" >> "$ERROR_LOG"
fi

七、总结

这次故障给我最大的教训是：运维监控不能只盯着"磁盘空间"这一个维度。

Linux文件系统中的inode和blocks是两个独立的资源。df -h只看blocks（数据块），df -i看inodes（索引节点）。很多运维工程师只关注前者，直到某天服务器磁盘"明明有空间却写不进去"才恍然大悟——原来还有inode这回事。

这次排查也让我意识到ARG_MAX这个内核参数在批量文件操作中的真实影响。日常运维中find -delete用得很多，通常不会出问题，但当文件数量达到百万级时，它就会成为隐藏的炸弹。xargs分批处理是一个简单而有效的解决方案，成本极低但能把系统稳定性提升一个量级。

最后，“能写文件的磁盘就是好磁盘"是一个危险的假设。生产环境中，inode的消耗通常比blocks更隐蔽、更难以发现，因为小文件对物理空间的占用微乎其微，但每个文件都必须消耗一个inode。对于频繁创建临时文件的应用，inode耗尽的速度可能远超你的想象。