本文作者洪志国，原文发布于个人技术博客。作者基于 Cube Sandbox v0.1.1 测试环境对其存储架构进行了一次深度拆解，公众号经作者同意，对原文做了少量适配性编辑。

如果你已经在用 Cube Sandbox，可能会想过几个问题：

这些问题不影响你"用"Cube，但会影响你信任它、调优它，或者真的把它跑到生产。我自己最近想搞清楚这些，就在一个 v0.1.1 的测试环境里把存储这条链路从头到尾扒了一遍。

整个过程比想象中要曲折，还顺手扒出了一个我觉得可能有问题的设计（先卖个关子，文末讲）。这篇就把我看到的东西整理出来，希望对你有用。

Cube Sandbox 的运行时模型是“宿主机 → 微虚机 (MVM) → 容器”这样一个三层夹心。要看清存储架构，最方便的入口是微虚机的配置文件 vm.info。

以一个 sandbox（id 取头一段 4d656bd3...）为例，可以通过一条命令拿到它的完整 vm.info：

curl --unix-socket /run/vc/vm/4d656bd3.../chapi \     http://localhost/api/v1/vm.info | jq

vm.info 里包含了这台微虚机的所有秘密——内核启动参数、虚拟块设备清单、virtiofs 挂载、网络配置等等。后面的所有分析，都是从这个文件里反推出来的。

另外，Cube 启动一台沙箱有两种入口：

这两条路径在"存储"这一块走的不是同一条流水线。下面分开讲。

从镜像创建 sandbox 的存储架构总览图

{  "volumes": [    { "name": "rootfs-wlayer", "volume_source": { "empty_dir": { "SizeLimit": "1Gi" } } },    { "name": "tmp",           "volume_source": { "empty_dir": { "SizeLimit": "2Gi" } } }  ],  "containers": [    {      "name": "nginx",      "image": { "image": "nginx:latest" },      "command": ["sleep"], "args": ["1000000"],      "volume_mounts": [        { "name": "rootfs-wlayer", "container_path": "/" },        { "name": "tmp",           "container_path": "/mnt1" }      ],      "resources": { "cpu": "500m", "mem": "512Mi" },      "security_context": { "readonly_rootfs": false }    }  ]}

注意两个 empty_dir：一个挂到容器根目录 /（其实是当作可写层用），另一个挂到 /mnt1（类似 k8s 的 emptyDir 临时卷）。后面会看到它俩在虚机里其实是两块 virtio-blk 磁盘。

执行 cubecli cubebox create req.json，沙箱起来了。下面开始一块一块磁盘看进去。

从 vm.info 的 .config.payload.cmdline 字段可以看到：

root=/dev/pmem0 rootflags=dax,errors=remount-ro ro rootfstype=ext4

这说明微虚机的根文件系统挂在 /dev/pmem0 上，只读、启用 DAX。

进一步从 .config.pmem[0].file 找到这个 pmem 的真身——宿主机上的一个 raw image 文件：

/usr/local/services/cubetoolbox/cube-image/cube-guest-image-cpu.img

可以手动 loop 挂载验证，里面就是一个标准的 ext4 文件系统。

这里 Cube 做了两件挺聪明的事：

如果你在一台宿主机上跑十几个沙箱，这一条直接省下十几份系统盘缓存的内存开销。

💡 小结：微虚机系统盘 = 宿主机上的一个 raw image + pmem + DAX 只读挂载。多沙箱共享，零 page cache。

容器镜像这一块走的是相对"传统"的路线：

镜像先被 cubelet 下载到宿主机，并按 containerd 的 overlayfs snapshotter 展开：

/data/cubelet/root/io.containerd.snapshotter.v1.overlayfs/refs/default├── f68a8bcb.../{fs,work}├── cbf2c778.../{fs,work}├── 894f3fad.../{fs,work}└── a464c54f.../{fs,work}

每个子目录是镜像的一个 layer。然后 Cube 通过 virtiofs 把这些 layer 目录透传给微虚机——vm.info 的 .config.fs 部分里能看到 4 个 layer 全部 mount 了进来，tag 统一是 cubeShared。

但注意 virtiofs 的一个关键参数：backendfs_config.cache = 2。

Cube 选了最激进的 always。这意味着：镜像内容会在微虚机里产生 page cache。如果同一台宿主机上 10 个沙箱用同一个镜像，会产生 10 份重复的 page cache——这个跟系统盘 pmem 的"零 cache"形成了一个有意思的反差。

不过考虑到容器镜像在沙箱里是高频读取的、且 Cube 这里追求的是"启动快"，这个权衡是说得通的。

💡 小结：容器镜像 = 宿主机 containerd 解压成 layer + virtiofs 透传给微虚机。性能优先，会有重复 page cache。

这一节是 Cube 工程细节最密、也最值得拆出来讲的部分。

vm.info 里有两个 virtio-blk 磁盘（vda、vdb），对应宿主机上 /data/cubelet/storage/io.cubelet.internal.v1.storage/emptydir/ 目录下的两个 raw image 文件：

emptydir/├── 1Gi/│   ├── 0/{16ab39..., 7cdb97..., base.raw}│   └── 1/{0c8cfd..., 0ebae4..., base.raw}├── cubebox/└── othersv2/    ├── 0/base.raw    └── 1/{4b4302..., base.raw}

每个 UUID 文件就是一个微虚机 virtio-blk 设备的后端，初始内容是一个空的 ext2 文件系统。1Gi 的放 1Gi/ 下，其他容量的放 othersv2/。

那么问题来了——沙箱启动那一刻，这些"空磁盘"是从哪冒出来的？格式化一个 ext 文件系统不是瞬间能完成的事，为什么 Cube 能做到几十毫秒起一个沙箱？

答案是两层优化叠加：reflink + 预热池。

reflink（Copy-on-Write Link）是支持 CoW 的文件系统提供的高效文件克隆能力。

对 Cube 这个场景来说，这等于：一个 1GiB 的 base.raw 可以瞬间"复制"出一堆派生文件，磁盘几乎不占额外空间，IO 也几乎为零。

但 reflink 有一个硬性前提——底层文件系统必须支持它。目前 ext 系列不支持，xfs 和 btrfs 支持。所以官方建议 /data/cubelet 用 xfs；cubelet 启动时 plugin.go 的 checkPoolType() 会自动探测，不支持 reflink 就回退到普通拷贝——能跑，但启动会慢一些。

如果你在生产里跑 Cube，这是一个一定要确认的部署细节。

光有 reflink 还不够——cubelet 把这条优化又往前推了一步：连 reflink 这一步本身都提前做掉。

配置项 PoolDefaultFormatSizeList（默认 ["1Gi"]）声明了要为哪些容量做预热。以 1Gi 为例：

base.raw 本身的创建逻辑在 newExt4BaseRaw() 函数里，流程是：

touch → truncate → mkfs.ext4 → mount → mkdir → umount

这是一次性的、相对耗时的"格式化 + 初始化目录结构"。但只要做一次，后续所有需要 1Gi 可写层的沙箱都能直接"拎走一个"。

如果请求的可写层容量经过 normalizeRootfsSizes 规整化后没有落在预热池里（比如 2Gi、5Gi），就会走 othersv2/ 路径。

othersv2/ 也有 100 个预创建子目录、每个里面也有 base.raw，但不预先 reflink。当请求来了，cubelet 现场做：

reflink(base.raw → new.raw) → truncate → e2fsck → resize2fs

—— 把基础镜像 reflink 出来，再 truncate 到目标大小，跑 e2fsck 修一下文件系统，最后 resize2fs 把文件系统真正撑到指定容量。

这条路径比预热池慢，但比"从零格式化"还是快得多。

💡 小结：Cube 把"几十毫秒起一个沙箱"做到的关键秘诀之一，是把磁盘准备的成本拆成两层往前移——base 文件系统预先 mkfs 好，常见容量的 reflink 副本也预先做好；沙箱真正启动时，只需要从池子里"拎走一个 inode"。

📌 作者注：这块逻辑在后续新版本中发生了巨大变化，后面有空专门再梳理一下。本文基于 v0.1.1，仅作为参考。

登进微虚机看一眼挂载：

bash-5.2# mount/dev/pmem0  on / type ext4 (ro,relatime,errors=remount-ro,dax=always)/dev/vda    on /run/blk-cube/vda type ext4 (rw,relatime)/dev/vdb    on /run/blk-cube/vdb type ext4 (rw,relatime)cubeShared  on /run/cube-containers/shared/containers type virtiofs (ro,relatime)overlay2 on /run/cube-containers/b48b9c8.../rootfs type overlay   (rw,    lowerdir=/run/cube-containers/shared/containers/{f68a8bcb..,cbf2c778..,894f3fad..,a464c54f..}/fs,    upperdir=/run/blk-cube/vda/disk/b48b9c8.../upper,    workdir =/run/blk-cube/vda/disk/b48b9c8.../work)

最后那条 overlayfs 挂载，就是容器真正的 rootfs。逻辑很清晰：

至于 vdb，对应 req.json 里那个挂到 /mnt1 的 emptyDir——通过 bind mount 暴露到容器里就行了。

到这里，从镜像启动的整条存储链路就串完了：

宿主机 raw image (pmem 只读根) + 宿主机 containerd layer (virtiofs 透传) + 宿主机预制空磁盘 (virtio-blk 可写层) → 微虚机 overlayfs 合并 → 容器 rootfs

如果你用的是 E2B 协议，那 sandbox 必须从模板（快照）创建。这条路径跟前面主要差在"容器镜像怎么从宿主机进到微虚机"这一步。

从快照创建 sandbox 的存储架构总览图

快照包含三部分，分别落在两个目录下：

/usr/local/services/cubetoolbox/├── cubebox_os_image/│   └── rfs-32b1e04a.../│       ├── rfs-32b1e04a....ext4    ← 容器镜像合并视图，打包成 ext4 raw image│       ├── rfs-32b1e04a....vm      ← 微虚机内核二进制│       └── version└── cube-snapshot/cubebox/    └── tpl-kvm-1/2C4096M/        ├── metadata.json        └── snapshot/            ├── config.json            ├── memory-ranges       ← 内存快照            └── state.json          ← CPU 状态

注意 .ext4 文件——这是 Cube 启动加速的关键设计：把容器镜像所有 layer 合并叠加之后的视图，整体打包成一个 ext4 文件系统。这样从快照启动时，不需要再走 containerd 的解压流程，一个文件直接挂上去就能用。

进微虚机看：

/dev/pmem0 on / type ext4 (ro, dax=always)/dev/pmem1 on /run/cube-containers/sandbox/pmem-cube/pmem1 type ext4 (ro, dax=always)   ← 新增/dev/vda   on /run/blk-cube/vda type ext4 (rw)

多了一个 /dev/pmem1——就是上面那个 .ext4 镜像合并视图，以 pmem + DAX 方式挂载。

然后 overlayfs 就用 pmem1 作 lowerdir，vda 作 upperdir，跟从镜像启动的拼装方式一样。

把两种方式对照一下就一目了然了：

所以走快照这条路，不仅是为了 I/O 快、内存省，更是为了启动快。 这也回应了为什么 E2B 协议要求"sandbox 必须从模板创建"——快照不只是"省心"，它本身就是性能模型的一部分。

不过对于不走 E2B 协议、直接从镜像创建沙箱的场景，镜像如果也能用 pmem 方式（即接入"打包成 ext4"这一步），I/O 性能和内存开销都会更优。缺点是要多一步"打包"的工序。这或许是 Cube 后续可以优化的一个方向。

上面 3.1 节里我列了快照保存的目录结构，仔细看的话其中少了一样东西——微虚机的系统盘镜像 cube-guest-image-cpu.img。

从快照拉起一台沙箱时，微虚机系统盘总是固定使用宿主机上 cubetoolbox/cube-image/cube-guest-image-cpu.img 这个文件——它没有被打包进快照。

这意味着：

如果在 T1 时刻基于 v1 版本的 cube-guest-image-cpu.img 打了一个快照；之后宿主机上的这个 image 文件被升级到了 v2；那么 T2 时刻从这个快照恢复出来的沙箱，微虚机系统盘已经是 v2 而不是当初打快照时的 v1 了。

正常情况下，guest image 是向后兼容的，但如果某次升级里改了 init 流程、改了内核命令行解析逻辑，或者新增了对某个内核版本的依赖——从老快照恢复出来的沙箱行为，可能就和"当初打快照那一刻"对不上了。

类似的事情对内核二进制是处理过的——.vm 文件就是为了避免快照里的内存状态和宿主机上 vmlinux 的符号表对不上而单独存的。但系统盘镜像这一份，看起来还是被漏掉了。

后续我会尝试给社区提一个 PR，把系统盘镜像也纳入快照打包流程，让"从某个快照恢复"真正意味着"完全回到打快照那一刻的状态"。如果你也在生产里跑 Cube，建议先关注一下这个点，避免在 guest image 升级期间踩到。

把这条链路扒下来之后，我对 Cube 的整体观感是：

几个让我印象深的设计点：

当然也有可以改进的地方——比如上面提到的快照里少打包了系统盘镜像，比如直接从镜像启动场景下镜像还没法用 pmem 方式。

这些都是开源项目自然的成长空间，也是社区共建可以发力的地方。Cube 的代码我读下来风格挺清爽，新人友好度还不错，有兴趣的同学可以一起来看看。

🔗 GitHub 仓库： https://github.com/TencentCloud/CubeSandbox

📝 本文作者博客：https://honkiko.github.io/p/cubesandbox-storage-analysis/

💬 欢迎在 GitHub issue 或 Cube Sandbox 社区群里继续交流。如果你也在扒源码、找设计点，欢迎投稿。