吾等Discord中一友言，微沙盒之感迟缓。列Python标准库中诸文件，于沙盒内需时五点三秒；而于Docker，仅须毫厘之间。吾等遂深究之。

吾等更之於v0.4：易吾等之用戶空間文件系統爲Linux之硬盤影像，虛機直掛之。吾等混雜之客觀文件系統套件，其幾何平均加速率四十七倍，最劣之列超千倍，而主機文件系統之碼約五千三百行短。

吾初試爲monofs：此乃一以内容寻址之文件系统，具区块级之去重、压缩，并设分布式读副本。其存图像于盘，仅及其原体积之1.3倍，且微沙盒以本地为先，故长尾去重之利，不偿其初置之费。至v0.3时，吾改用OCI，并加用户空间之覆盖层，此层基于libkrun之钩子构建；得层级去重，且于Linux与macOS行为无别，然万般皆在内核之外运行。

凡VM之中文件之操作，必经由FUSE反弹至主系统，FUSE者，Linux之机制，使寻常程序可扮作文件系统也。欲开一文件，VM将请托付予主程序，主程序遍寻诸层以觅此文件，复将答案返之；每有stat、readdir，及缓存失之情形，皆循此途；一Pythonimport 起动之前，辄触数十此迂回；十重图像，更倍其费。

吾辈继之，于v0.3时，力图其径之速：善其缓存，减其系统调用，缩其响应。每变损其数分。皆未易其量级。

Docker无此弊，盖 Docker用核之自层数据驱动（overlayfs），故文件之动未尝出核。吾辈尝欲外核求核之层数据，无缓存可弥其隙。

是故去其层数据。

新策在，止诸文件之操作，不往复于虚拟机与主机间。吾辈当预先构 Linux 文件系统之像，授虚拟机为虚盘，使虚拟机自核自载之。FUSE 既出其外，则虚拟机内之文件操作，自可存于虚拟机内。

吾所择之文件系统者EROFS：唯读，自树中，因核需之故，用于安卓，且撰述易。EROFS亦解macOS之困：虚拟机自核，虽外运行何物，皆为Linux，故一旦磁盘影像成，主系统之文件系统即无足轻重。

微沙盒，行于Linux与macOS，然macOS缺主端之工器，常用于建文件系统影像：无mkfs.ext4，无。mkfs.erofs，无回环挂载。若吾之图像管线有所倚赖，则必或运一助VM（重，启动迟缓），或永存平台之别，二者皆非微沙盒“单一自包二进制”之诺言所宜。是故吾等以Rust自撰图像之撰。文件系统者，磁盘之字节布局也；撰者惟产此布局耳。三小物成其事：

• 。EROFS作者发唯读之像于OCI层者。
• 一ext4写入者彼发疏阔，记事之痕，每沙盒得之。
• 一VMDK描述符此能织诸事于一片虚盘之中。

管中无物，不索根权，亦不载回环之器，而同此 Rust 代码径，于 Linux 及 Apple Silicon 上建像，不假他山之工。EROFS 之遗物，经吾所撰之读器往返，CI 则于真 VM 核下启全栈。若一宇之误，二读器必告之。

用此写器之显道，每 OCI 层一 EROFS 图像。 虚拟机每层得一虚拟磁盘，复一于 scratch 区，而核之 overlayfs 于启动时合之。效验：首测速较 v0.3 快十至百七，视负载而定，遂可发之。

继而数其层数。一Python之像约十；CUDA之像或多；有用户所建者，竟至三十四十。微VM之制，限其可载之器，吾辈每层附一磁盘焉。举冠然真解在于，止用虚拟磁盘示VM“此像有层”之时， filesystem自可承此信息。

EROFs(EROFs的朋友们)示吾辈一未尝用之功能：EROFS可建一元数据之像，惟合并之目录树，兼每文件一指针，示其字节所存之底块及其偏移。核读此像，视全束若一虚盘，应每查寻，惟一算即得，非遍索诸层。

是故，其流为：

• 循常引OCI诸层。
• 构一微元元数据之像，状合木之形.
• 授虚拟机一灵盘，使元数据与层块相缀合。

今之虚拟机，唯需接二根文件系统块设备，无论原镜像层叠几何：一为只读之VMDK栈，承原镜像（其内引合并元数据之镜像及各层EROFS之范围），一为可写之ext4上层，供沙箱之用。Overlayfs恒合此二者。此即所发行之版本，稍。之内核配置微调 (CONFIG_EROFS_FS_XATTR + CONFIG_EROFS_FS_SECURITY) 俾 EROFS 显 xattrs 之 overlayfs 所需以覆白出。

拉取之际，主體化 OCI 层為 EROFS 之件，以差異 ID 索，合層元資料於本源，書 fsmeta.erofs，並發 VMDK 之記。fsmeta.erofs 並層之延。沙盒創立之際，微沙盒為此沙盒創一疎upper.ext4。啟動時，客體見僅讀下層堆為/dev/vda，可寫上層堆為/dev/vdb，而Linux之疊戴文件系統/之。

吾等于python之像，对二版本，三度运行同套基准。每度运行皆新启状态。于十四项混合客机可见之文件系统作业，其几何平均加速倍数为四十七倍有余。，而八项最大变动者列于下.

此柱状物分为二类：

• Rootfs路径：此乃新OCI路径之最洁净量度；今此操作皆存于客核之中，不复经主核跳转.
• /tmptmpfs：客显之胜，实因削FUSE往返于客tmpfs作业，非新EROFS下rootfs路径所致。

metadata_scan_stdlib 考察 Python 之標準庫中每一檔案之元資料。昔者半秒而就，今者僅需二毫秒耳。

Linux之overlayfs，乃一宏大之规范，涵括白名单、不透明目录、跨拷贝硬链接、目录重命名，及若干xattr之惯例，皆须恰如其分。吾等v0.3于用户空间重实现之，然吾等删除之日，犹在追索边缘案例。v0.4则未重实现之，盖虚拟机自内核已为之合并，旧时之bug未得修复；今已消弭矣。

主仍须通晓OCI层之理，然惟一次，在引时也。白除、不透明目录、硬链接、扩展属性、区分大小写路径，皆于fsmeta.erofs书之前，化入合并之元数据树。其后，运行路径即寻常之内核EROFS与overlayfs也。

macOS之APFS，默认不区分大小写。多Linux镜像含文件名仅大小写异者，往昔提取于Mac，则后者必归并前者。v0.4永不复提取至主文件系统；EROFS写入者将tar流直送二进制镜像，其中文名与原名皆存为磁盘上独立条目。

盖因根文件系统今为真磁盘镜像，故周遭产品界面愈廉。

• OCI之补丁. 根文件系统之补丁，用户欲置于镜像之上者，于启动前即烙印于upper.ext4，而非以运行时覆盖协议铆接之.
• 共通之下层. 各层之EROFS产物，以差异ID标示其内容，故二隔离沙箱共用一基础镜像者，其字节既存于磁盘，复驻于缓存.
• 快照。 砂盒可写状态，乃一ext4之文件；保存或复制之，即文件之复制也.
• 磁盘映像之根. 定制非OCI磁盘映像根文件系统，复用同块设备启动之机，唯无fsmerge步骤于其前.

唯OCI根文件系统而已. 绑定卷（你共享至虚拟机的宿主机目录）仍循旧径。其内容，虚拟机读之，可随时更迭，然唯读磁盘镜像，难状其变.

初次拉取，非速也. 今于拉取之际，更勤其工以建镜像，虽层间并行而受tar解压所限，故其效近旧，后续沙盒所创之，速也，盖惟发疏影耳。

于影之写，犹袭写为变。欲改影中篇，则影上抄入可写之层，恰若诸叠设。根之胜在此，乃于寻读繁重之途；/tmp之生灭，胜于图之来者。/tmp 乃客侧tmpfs之常，别为运行时之决断也。

核心之庸术，常胜用户空间之巧策。 既有单文件系统，复有吾等v0.3之覆盖系统，皆雄心勃勃之设计也。然EROFS乃内核中文件格式，平淡无奇，而沙盒根文件系统，平淡者胜。吾等费时月余，调适用户空间之码，终悟结构之解，在于止竞内核，而用之。

NIH之策，于既有之物破坏汝之设计时，尚可。 欲求mkfs.ext4，则需出壳。mkfs.erofs 若为助VM或独用Linux之分裂，皆将毁微沙盒"一自成一统之独体"之诺。自为写作者，乃守此诺之代价，吾等复当易此交易。

舍中仍持佳思。吾初裁已然大胜，几欲即行。EROFS所倡之洁形，初时似为可欲之具，然持此PR再延一周以纳之，遂使偶发之优化，变为吾乐于长持之事。

于虚拟机中运行基准测试。 若以主机之时计，则FUSE往返之弊可隐，胜负之形亦减。当计时用户所待之事。

此功能载于微沙盒0.4及以后版本。安装CLI：

curl -sSL https://install.microsandbox.dev | sh

或用适于汝语言之SDK：

uv add microsandbox       # python
npm install microsandbox  # typescript
cargo add microsandbox    # rust

基准测试别置一库，俾可渐成跨运行时之比较。以 msb 而行。PATH与鲜段~/.microsandbox：

git clone https://github.com/superradcompany/sandbox-bench
cd sandbox-bench/benches/fs
just bench-quick

需just与uv。