概要
2026 年 5 月 31 日，在 WSL 里反复拉取 ghcr.io/euro-office/documentserver:latest 时，镜像始终没有成功完成。重试过程中，大量临时容器存储累积在 WSL 内部，尤其是 /tmp/podroot/vfs 以及相关路径，进一步撑大了 WSL 的虚拟磁盘 ext4.vhdx，并占用了宿主机 C: 盘的可用空间。
影响
- 宿主机
C:盘可用空间明显下降。 - 事故高峰时，WSL 根文件系统占用接近
81 GB。 - Ubuntu 的
ext4.vhdx扩大到约81.81 GB。 - 宿主机剩余可用空间降到约
164 GB，低于历史上的232-234 GB水平。
发现方式
- 在 WSL 中使用
du和find发现/tmp下的占用异常大，其中/tmp/podroot/vfs约占73 GB。 - 拉取
documentserver的 Podman 进程一直活着，但基本没有明显进展。 podman images中没有看到documentserver成功导入的镜像。
时间线
- 在 WSL 中通过 Podman 开始拉取
ghcr.io/euro-office/documentserver:latest。 - 拉取过程多次卡住，期间尝试了自定义
vfs路径和默认overlay路径。 - 临时层和缓存文件大量堆积在
/tmp/podroot*与/var/tmp/storage*。 - 在 WSL 内部清理后，删除了约
72 GB的临时数据。 - 但宿主机空间并没有立刻恢复，因为
ext4.vhdx仍然保持扩容后的大小。 - 通过
wsl --shutdown加diskpart compact vdisk的流程压缩了 WSL VHDX。 - 宿主机空间恢复，
C:盘可用空间回到约237.29 GB，ext4.vhdx缩回到约8.71 GB。
根因
主要根因：
- 在 WSL/Podman 中反复尝试拉取一个较大的 DocumentServer 镜像，生成了大量临时容器存储和缓存数据。
促成因素：
- 部分尝试使用了
vfs存储路径，I/O 开销更大，临时占用也更重。 - 拉取卡住后，残留了工件、锁文件和状态数据，但没有产出可用镜像。
- WSL 的动态 VHDX 在宿主机上不会因为 Linux 内部删除文件就自动缩回去。
处理结果
- 停掉了卡住的拉取进程。
- 删除了
/tmp/podroot*、/tmp/podrun*以及/var/tmp/storage*下与失败拉取相关的临时文件。 - 确认 WSL 内部占用从约
81 GB降到了6.8-8.4 GB区间。 - 在宿主机上对 WSL 磁盘文件执行压缩，恢复了 Windows 文件系统中的已释放空间。
预防和改进
- 除非确有强制需求，避免在大镜像拉取场景下强行使用
--storage-driver=vfs。 - 在拉取大镜像前增加预检查：
- WSL 内部和宿主机剩余空间
- 容器运行时健康状态
- Registry 连通性和认证行为
- 遇到失败或卡住的拉取任务时，标准化清理流程：
- 停掉卡住的运行时进程
- 清理已知临时和缓存路径
- 检查镜像和容器状态
- 必要时压缩 WSL VHDX
- 如果在 WSL 中反复遇到大 OCI 镜像卡顿，可以考虑升级 Podman 或相关运行时栈。
恢复后的验证
C:盘可用空间：约237.29 GB- Ubuntu
ext4.vhdx：约8.71 GB - 失败尝试遗留的
documentserver镜像和容器状态已经清空