[Research Epic] Build snapshot-multiplexed monorepo workspaces for a ScorpioFS systems paper

[Ivanbeethoven]

背景

ScorpioFS 已经具备 Antares 三层工作区：

private upper (RW)
optional CL layer
shared Dicfuse lower (RO)

但当前版本尚不足以支撑完整系统论文，主要原因是：

1. base_revision 目前主要是控制面 provenance，实际 Dicfuse lower 仍按最新路径数据读取；
2. Dicfuse 实例主要按 base_path 复用，而不是按不可变 revision/tree snapshot 复用；
3. 持久化内容缓存按 inode 存储，无法自然完成跨快照、跨工作区内容去重；
4. 每个 Antares workspace 都创建独立 FUSE session，工作区数量增加后会重复承担挂载、内核缓存预热和生命周期管理成本；
5. 当前预取策略主要是静态 depth/hotset/scan 模式，缺少预算、优先级、请求合并和多租户公平性；
6. 现有性能文档属于工程测试，尚缺统一基线、冷/热缓存定义、尾延迟、置信区间、故障注入和端到端 Agent/Build workload。

论文假设

需要通过 Issue 1–11 验证，而不是预先当作结论：

对于 N 个工作区和 U 个唯一基础快照，ScorpioFS 的 lower 实例、持久化内容和远端读取成本应主要随 U、唯一访问工作集及各工作区增量增长，而不是随 N × repository_size 增长。

目标资源模型：

ResourceCost ≈ SharedUniqueWorkingSet + Σ WorkspaceDelta_i

而不是：

ResourceCost ≈ N × MaterializedCheckoutSize

预期论文贡献

1. Revision-pinned lower snapshots
   用不可变 commit/tree identity 定义 Dicfuse lower，支持多个版本并存。

2. Snapshot multiplexing
   让多个工作区复用同一个 snapshot lower、内容缓存和远端请求，使昂贵的 FUSE/lower 成本随唯一快照数而非工作区数增长。

3. Provenance-aware delta index
   在首次 copy-up、删除或 rename 时记录基础对象身份，避免反复扫描 upper，并支持确定性重建、冲突检查和选择性清理。

4. Multi-tenant fetch and prefetch control
   提供 single-flight、优先级、公平性、取消和预算化预取，避免并发 Agent 造成重复下载和缓存污染。

5. Reproducible systems evaluation
   提供 trace、replay、真实构建、并发扩展和 crash-consistency 评测。

论文研究问题

• RQ1 — Snapshot correctness: 工作区是否始终对应绑定的不可变版本？
• RQ2 — Provisioning: 工作区创建和销毁延迟能否不再依赖仓库 materialization？
• RQ3 — Sharing: 并发工作区能消除多少重复元数据请求、blob 下载和磁盘占用？
• RQ4 — Density: 单机工作区数量增加时，CPU、内存、FUSE session 和尾延迟如何扩展？
• RQ5 — Prefetch: 在固定网络/缓存预算下，语义预取是否优于静态扫描？
• RQ6 — Recovery: daemon crash、网络失败和刷新中断后，能否恢复到唯一、可解释的 generation？
• RQ7 — End-to-end: 对真实 Buck2/Bazel/Cargo/CMake 和 Coding Agent 工作流有多少收益？

非目标

• 不把 ScorpioFS 宣称为完整安全 sandbox；
• 不在本项目中重新实现 Git refs、index、merge/rebase 和凭据管理；
• 不以“使用 Rust/FUSE/OverlayFS”本身作为论文创新；
• 不以单个微基准吞吐量作为主要论文结论；
• 不在没有 trace 证据之前假设 Coding Agent 一定具有某种访问局部性。

子 Issue 与依赖

M0 Measurement
  Issue 1  Telemetry and trace
  Issue 2  Reproducible benchmark harness

M1 Snapshot correctness
  Issue 3  Revision-addressable backend and SnapshotId
      ↓
  Issue 4  Shared content-addressed cache
      ↓
  Issue 5  Transactional generation switch
      ↓
  Issue 6  Provenance-aware delta manifest

M2 Dense-workspace scalability
  Issue 7  Shared FetchCoordinator
      ↓
  Issue 8  Shared snapshot-lower architecture
      ↓
  Issue 9  Budgeted semantic prefetch (optional main-paper mechanism)

M3 End-to-end and artifact
  Issue 10 Libra/Orion integration and correctness oracle
      ↓
  Issue 11 Full evaluation and artifact release

完成标准

• Issue 1–8、10、11 完成并形成稳定实验数据；
• Issue 9 只有在达到论文收益门槛时进入主论文；
• 至少有两个真实大型项目和一个可控合成 monorepo；
• 至少支持并发度 1/4/16/64；
• 所有核心 claim 都能由脚本和机器可读结果复现；
• 正确性、性能和故障恢复均有独立实验；
• 论文 artifact 不依赖私有生产数据才能运行。

---