递归chown从4秒变1分钟，他们用块设备把性能拉回12倍

一个递归 chown 命令，在容器里跑完只要四秒。搬到虚拟机里，同样的命令花了一分多钟。这不是配置写错了，是文件系统架构选错了路。

Modal 团队最近把 VM Sandboxes 推上正式可用，支撑的是越来越复杂的智能体工作负载。沙箱里的一切，归根结底都压在文件系统的速度上。他们把这段从踩坑到翻盘的过程完整讲了一遍。

起点：ImageFS 和亚秒级冷启动

2022 年 4 月，Modal 用 ImageFS 解决了容器文件系统的问题。这是一套分布式的惰性加载文件系统：启动时只拉取最少的元数据，通过一个 Rust 写的 FUSE 服务挂载，再把文件呈现给容器。文件内容按需从分层的内容寻址缓存里取，从本地内存到区域 CDN，再到全局对象存储。后台还有智能预取，访问几乎总能命中本地磁盘或内存里的文件。

这是 Modal 容器能在一秒内冷启动的主要原因。传统 Docker 要花几分钟拉取和解包镜像层，ImageFS 只需要在启动前加载元数据索引，毫秒级完成。而且它虽然是 FUSE 实现，速度并不慢——只读的特性让它能告诉内核激进缓存每一个应答过的请求。

写操作交给 OverlayFS：把只读的下层（也就是 ImageFS）和可写的上层合并，所有文件改动都落在上层文件的副本上。

虚拟机里的第一版：virtio-fs

设计虚拟机时，团队想继续复用 ImageFS，把容器那套体验继承过来。问题是容器和宿主机共享 Linux 内核，能直接用 ImageFS；虚拟机有完整的客户机内核，碰不到宿主机的文件系统。

virtio-fs 就是补这个缺口的：它把客户机虚拟机的文件系统操作转发到宿主机的 virtiofsd 守护进程，由后者安全地作用在共享目录上。指向 ImageFS，虚拟机就能继承惰性加载、亚秒冷启动和分层缓存。

确实跑通了。虚拟机从同样的镜像启动，冷启动性能和容器一致。于是他们准备发布。

但冷启动快，不等于用起来快。

virtio-fs 只是在原有 ImageFS 栈上又加了一层，多做事自然更慢。可实际差距远超预期：递归 chown 从四秒变成一分多钟，pnpm install 和 bun install 这类真实负载慢了三倍，ripgrep 性能直接断崖。

拆解 bun 和 pnpm 的系统调用后，他们做了合成微基准测试，对比三种情况：宿主机直接用 ImageFS、gVisor 后面用、虚拟机里走 virtio-fs。结果是 stat 在 virtio-fs 下慢 2 倍，chown 慢 6 倍以上。

追踪 virtiofsd 的系统调用，chown 的真相浮出来了：

• chown 以 fchownat 离开客户机进程，进入客户机内核；
• 客户机内核检查并清除文件能力，向虚拟机外发一个 FUSE_GETXATTR 给 virtiofsd，后者检查文件并回复，消耗 3 次宿主机系统调用；
• 客户机内核还要检查并清除 setuid 位，再发一个 FUSE_GETATTR 给宿主机；
• 最后所有权变更以 FUSE_SETATTR 发出，virtiofsd 改完属主，返回更新后的文件属性。

一次 chown 需要客户机到宿主机三次往返，virtiofsd 发出六次宿主机系统调用，每一次都落在 ImageFS 上。而这还是在 virtiofsd 已经调到最大缓存和合并操作的前提下。

文件带着元数据：名字、属主、权限。每一个元数据操作都必须去问元数据的权威方。virtio-fs 把这个权威方放在虚拟机边界的另一侧，客户机永远只是个客户端。哪怕宿主机侧根本不需要读虚拟机的根文件系统，它依然是一套共享文件系统。

换一种语言：说块

如果让文件系统完全活在客户机里呢？元数据全在客户机内解释，宿主机只剩一件事：存字节，需要时还回去。

这种安排有个现成的名字——块设备。块是硬盘和 SSD 说的语言，它们不知道文件是什么，只处理数据块。ext4 这类文件系统，本质上就是文件语言到块语言的翻译器。

Linux 内核在块设备上打磨了几十年。物理机靠 HDD 和 SSD，虚拟机靠 virtio-blk，也就是 virtio-fs 的块设备对应物。更关键的是，客户机内核把每个能访问的块设备都当作独占的，没有任何文件系统操作需要去问别人。

同样一个 chown 走 virtio-blk：

• 以 fchownat 进入客户机内核，和之前一样；
• 客户机内核检查并清除文件能力，因为 ext4 驱动就在客户机内核里；
• 检查并清除 setuid 位，同样不需要向外调用；
• ext4 完成所有权变更，写入预写日志。

宿主机直到 ext4 刷出一批自上次提交以来的写操作时才知道发生了什么。成百上千次文件操作的成本被摊到一条块命令后面，而且是异步发生的，文件系统在此期间保持活跃。

代价是宿主机只会说块语言，失去了操作虚拟机文件系统的能力。换来的是所有操作——包括那些烦人的元数据往返——都留在客户机内，virtiofsd 那些额外的 FUSE 往返全部消失。

ImageFS-blk

块设备让虚拟机文件系统变快了，但怎么和 ImageFS 重新接上，保住镜像兼容和惰性加载？

直接调 mkfs.ext4 -d 造一个 ext4 磁盘再通过 virtio-blk 共享，行不通——那要求所有镜像内容提前就位，和惰性架构冲突。

他们换了个问法：怎么骗过客户机的 ext4 驱动，让它以为拿到的是完整镜像，实际按需供给文件内容？

ext4 为每个文件保留一条 inode 记录，存权限、大小和一组 extent，也就是代表文件数据的块区间。对请求的镜像，团队依然只提前拉取最少的文件元数据，用它自己写出 ext4 的 inode 记录。ext4 镜像的其余部分保持稀疏，只有客户机读取时才提供实际数据块。因为元数据是自己写的，块请求到 ImageFS 文件字节的映射早就有了。

宿主机上一个叫 ImageFS-blk 的守护进程处理 virtio-blk 过来的块请求，按映射惰性供给内容，不可变镜像和持久化写入分开处理。

写的时候，把块持久化到稀疏文件，在位图里标记为脏。稀疏文件只累积它支撑的那台虚拟机的写入，快照之类的操作只要查它就知道改了什么。读的时候，查映射把请求的块区间转成文件和字节区间，从 ImageFS 取；脏块和 ext4 元数据直接从稀疏文件读——逻辑上类似 OverlayFS，但发生在块层面。

设计阶段他们还发现，能跑赢 Linux 在 ImageFS 上的 OverlayFS 挂载。OverlayFS 修改不可变下层的文件前，必须把它复制到可写上层。常规配置下这很便宜：上下层在同一个 XFS 上，reflink 让两份副本共享底层数据，不用物理复制。但 ImageFS 的下层是 FUSE，上层是 XFS，reflink 失效。极端情况下，为了写几个字节要付出几个 GB 的开销。ImageFS-blk 在块层面做写时复制，最坏情况被限制在复制一个块。

加上预取，亚秒级冷启动回来了，启动也不需要下载整个镜像，同时享受客户机自管文件系统的好处。

基准测试

ImageFS-blk 把 virtio-fs 方案彻底甩开。同样的系统调用微基准：bun install 从 12.5 秒降到 1.07 秒，快了 12 倍。它甚至超过了经典 ImageFS，因为 ImageFS-blk 的元数据操作从不离开客户机，不走 ImageFS 的 FUSE 路径。代码导航和读吞吐也大幅改善。

收益延伸到数据库负载，pgbench 和 speedtest1 都有巨大提速，体现出块设备的效率。

VM Sandboxes 现已正式可用，后端就是 ImageFS-blk。