Docker镜像拉取解压阶段占用空间远超镜像大小导致边缘设备空间不足无法拉取的问题咨询

系统环境信息 #

我们公司在嵌入式Linux设备（Debian 9系统）上运行一款基于arm32v7/python:3.11-bullseye的Docker应用镜像，设备标配~6GB的eMMC内存，几乎全部空间都分配给了overlayfs，Docker的数据存储也配置在这个分区。

Docker daemon配置 #

{
  "graph": "/overlayfs/docker",
  "dns": [
    "8.8.8.8"
  ],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

镜像与空间基础情况 #

• 应用镜像拉取后的总大小为839MB，我在另一台正常运行的生产边缘设备上通过docker image ls确认过这个数值。
• 所有设备正常状态下，/overlayfs分区大概有4GB可用空间，之前部署同版本镜像时，设备的可用空间也处于这个水平。

问题描述 #

最近出现了一个非常奇怪的问题：把镜像从仓库拉取到边缘设备时，在解压阶段会直接占满全部4GB左右的可用空间，最终因空间不足失败，但可用空间明明远大于镜像本身的839MB。

更费解的是，这个镜像之前在相同设备上都能正常部署，而且镜像本身没有任何变更，设备的可用空间也和之前几乎没有差异。

具体报错信息 #

每次拉取的报错路径会有差异，但核心提示一致：

write /var/lib/docker/vfs/dir/< long hash here >/usr/lib/arm-linux-gnueabihf/libicudata.a: no space left on device

空间占用异常现象 #

拉取前的df -h输出（可用空间约3.9G）：

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        494M     0  494M   0% /dev
tpmfs           504M   48M  457M  10% /run
/dev/mmcblk0p2  446M  344M   75M  83% /
/dev/mmcblk0p3  6.6G  2.5G  3.9G  39% /overlayfs
overlay         6.6G  2.5G  3.9G  39% /var
overlay         6.6G  2.5G  3.9G  39% /etc
overlay         6.6G  2.5G  3.9G  39% /home
overlay         6.6G  2.5G  3.9G  39% /root
overlay         6.6G  2.5G  3.9G  39% /sbin
overlay         6.6G  2.5G  3.9G  39% /bin
overlay         6.6G  2.5G  3.9G  39% /usr
overlay         6.6G  2.5G  3.9G  39% /lib
overlay         6.6G  2.5G  3.9G  39% /tmp
overlay         6.6G  2.5G  3.9G  39% /mnt
overlay         6.6G  2.5G  3.9G  39% /opt
overlay         6.6G  2.5G  3.9G  39% /media
tmpfs           504M  4.0K  504M   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           504M     0  504M   0% /sys/fs/cgroup
tmpfs           101M     0  101M   0% /run/user/1001

解压失败前的df -h输出（空间被完全占满，仅剩193MB）：

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        494M     0  494M   0% /dev
tpmfs           504M   48M  457M  10% /run
/dev/mmcblk0p2  446M  344M   75M  83% /
/dev/mmcblk0p3  6.6G  6.2G  193M  98% /overlayfs
overlay         6.6G  6.2G  193M  98% /var
overlay         6.6G  6.2G  193M  98% /etc
overlay         6.6G  6.2G  193M  98% /home
overlay         6.6G  6.2G  193M  98% /root
overlay         6.6G  6.2G  193M  98% /sbin
overlay         6.6G  6.2G  193M  98% /bin
overlay         6.6G  6.2G  193M  98% /usr
overlay         6.6G  6.2G  193M  98% /lib
overlay         6.6G  6.2G  193M  98% /tmp
overlay         6.6G  6.2G  193M  98% /mnt
overlay         6.6G  6.2G  193M  98% /opt
overlay         6.6G  6.2G  193M  98% /media
tmpfs           504M  4.0K  504M   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           504M     0  504M   0% /sys/fs/cgroup
tmpfs           101M     0  101M   0% /run/user/1001

已经尝试的解决方法 #

我试过几种方案，但都没能解决问题：

• 执行docker system prune并删除无用镜像：结果完全没回收空间（0B reclaimed）。
• 彻底删除Docker VFS目录下的所有内容（/var/lib/docker/vfs/dir/）：虽然回收了拉取时占用的空间，但再次拉取时还是会出现同样的空间耗尽问题。
• 先把镜像用docker save导出为tar.gz包，拷贝到设备后用docker load导入：和直接拉取的情况完全一致，解压阶段依然占满空间后失败。
• 在边缘设备上直接构建镜像：拉取基础镜像的阶段就触发了同样的空间不足错误。

另外我也没找到任何可以限制Docker解压时临时空间占用的配置项，实在搞不懂为什么800多MB的镜像解压要吃掉4GB空间，而且之前同镜像同设备都能正常部署，最近突然就出问题了，希望能得到大家的帮助！

备注：内容来源于stack exchange，提问作者Sobek Sage