ubuntu:v1
+
python:v3
+
repo-B:v5
+
harness:v42
---
# 为什么这个设计非常牛？
假设：
N = 100,000 repositories
K = 20 toolkit versions
如果 monolithic image：
100,000 × 20
大量重复构建。
而 composable layer：
100,000 repo layers
+
20 toolkit layers
更新 toolkit：
只更新 toolkit layer
论文把这个复杂度从：
O(k × N)
降到：
O(k)
这一点是 DSec 很漂亮的系统设计。([arXiv][1])
---
# 第六课：为什么是 EROFS？
这里千万不要简单理解成：
> “EROFS 比 ext4 快。”
不是。
真正原因是：
> DSEC 需要一个 immutable + compressed + random-access + lazy-load 的 image representation。
传统：
tar.gz
是：
archive
↓
download
↓
decompress
↓
write everything
↓
start
假设：
image = 6GB
agent actually needs = 300MB
你还是得：
6GB
↓↓↓↓↓↓
download
↓↓↓↓↓↓
unpack
↓↓↓↓↓↓
write
---
# EROFS 的模式
变成：
EROFS
/ \
metadata data
│ │
local 3FS
│
on-demand
启动：
mount metadata
↓
sandbox ready
↓
Agent accesses /usr/bin/python
↓
page fault
↓
fetch required data from 3FS
↓
continue
也就是说：
> 不是“把 image 搬到机器上再运行”，而是“让 image 像一个远程只读文件系统一样存在”。
这是理解 DSec 的关键。
论文明确利用 EROFS 将 metadata 与 data 分离，并把 metadata 放在本地，而 data 从 3FS 按需读取。([arXiv][1])
---
# 于是 3FS 在这里扮演什么？
注意：
3FS 不是 Docker Registry。
它更像：
3FS
│
┌────────────┼────────────┐
│ │ │
Image Workspace Snapshot
│
▼
EROFS
│
on-demand
为什么？
因为 3FS 擅长：
large sequential IO
不擅长：
small random IO
所以 DSec 的设计是：
### Read
3FS
↓
bulk on-demand read
### Write
local disk
而不是：
sandbox writes → 3FS
因为 Agent 会疯狂产生：
small file
log
temporary file
package cache
...
这种小随机写会把 3FS 弄得很难受。
([arXiv][1])
---
# 这是 DSec 一个非常漂亮的“IO 分工”
Storage
┌───────────┐
│ 3FS │
└─────┬─────┘
│
large sequential
│
▼
READ IMAGE
│
│
▼
Sandbox
│
WRITE STATE
│
▼
local disk
Remote read + local write。
这不是偶然。
这是根据 3FS 的 I/O 性质反推出来的架构。
---
# 第七课：Container 和 MicroVM 的存储设计为什么又不一样？
这里开始进入“真正系统工程”的层面。
---
## Container
EROFS
EROFS
EROFS
↓
OverlayFS
↓
upperdir
↓
local disk
例如：
Base
↓
Workspace
↓
Toolkit
↓
Writable
---
## MicroVM
Firecracker 不能直接照搬这个设计。
所以：
EROFS
↓
read-only layers
OverlayBD
↓
writable ext4 disk
再通过：
ublk
暴露给 guest。
所以：
Host
│
│ 3FS
▼
OverlayBD
│
▼
ublk
│
▼
MicroVM
│
▼
ext4
论文特别提到，OverlayBD 可以支持：
on-demand read
local write
incremental snapshot
并且使用 256 KiB chunks + local second-level cache 来缓解小随机读取问题。([arXiv][1])
---
# 第八课：为什么 DSec 能塞下这么多 Sandbox？
现在进入另一个核心：
# Memory Overcommit
假设一台机器：
RAM = 1 TB
如果：
sandbox = 4 GB
传统：
1000 / 4GB = 250
但是 Agent Sandbox：
CPU usage 很低
所以 CPU 可以 overcommit。
但 memory 不行。
因为：
sandbox memory
guest page cache
host page cache
anonymous memory
都可能占住。
---
# MicroVM 的一个巨大浪费
假设：
Image data
被 guest 读取。
可能：
Host page cache
+
Guest page cache
出现：
同一份数据
↓
两份 cache
这非常浪费。
---
# DSec 的解决方案之一：virtio-pmem + DAX
核心思想：
3FS / backing data
│
▼
Host-backed pages
│
┌─────┴─────┐
▼ ▼
VM1 VM2
而不是：
Host cache
↓ copy
Guest cache 1
Host cache
↓ copy
Guest cache 2
这样可以让多个 microVM 共享 host page cache。
实验中：
> virtio-pmem + DAX 将 peak host memory usage 降低 **40.2%**。
