# ProfileMax Storage Hook / StorageFS 开发设计

> 项目：ProfileMax  
> 模块：ProfileMax Node Storage Hook  
> 目标：为 ProfileMax Node 上所有 Profile 数据提供统一存储入口，统一管理持久化磁盘与 tmpfs 临时存储。  
> 原则：IO 优先、低 CPU、不压缩、不依赖节点数据库；所有 Profile 数据访问均经过 Storage Hook。

## 1. 设计目标

Storage Hook 是 ProfileMax Node 上**所有 Profile 存储的统一入口**，不只是 Chromium Profile 主目录的磁盘分配器。Chromium、impersonate-proxy 以及 Profile 相关服务产生的文件，都必须通过 Storage Hook 管理。

Storage Hook 统一提供两类存储：

1. **持久化存储**：多磁盘 StorageFS，保存需要跨进程重启、Profile 重启继续存在的数据。
2. **临时存储**：由 Storage Hook 创建和管理的 tmpfs，承载可丢弃、可重新生成或已由代理层缓存的重复数据。

核心目标：

1. **IO 优先**：读写路径短，减少复制、锁竞争、系统调用和不必要的元数据操作。
2. **低 CPU**：不做压缩/解压，不做内容哈希，不在热路径执行复杂算法。
3. **避免重复缓存**：impersonate-proxy 已缓存的 HTTP 资源，不再让 Chromium 将同一份 HTTP Cache 持久化到磁盘。
4. **减少底层 inode**：按收益选择 Pack，不强制所有文件打包。
5. **统一入口**：所有 Profile 数据，包括 impersonate-proxy 的缓存目录，都由 Storage Hook 分配、挂载和监控。
6. **节点无数据库**：Storage Hook 不连接 PostgreSQL、SQLite、Redis 或 Admin 数据库。
7. **数据语义正确**：对 SQLite、LevelDB 等活跃数据库文件提供正确的锁、同步、重命名和随机读写语义。

不以压缩率、去重率或极限节省磁盘空间作为目标。

## 2. 总体架构

```text
                         ProfileMax Admin
                    (唯一配置数据库持有方)
                              |
                     Storage Hook 配置下发
                              |
                              v
+--------------------------------------------------------------+
|                        ProfileMax Node                       |
|                                                              |
|  Chromium Profile       impersonate-proxy   Profile Services |
|         |                       |                    |        |
|         +-----------------------+--------------------+        |
|                                 |                              |
|                                 v                              |
|                     Storage Hook (统一入口)                   |
|                                 |                              |
|             +-------------------+-------------------+          |
|             |                                       |          |
|             v                                       v          |
|     Persistent Storage                         tmpfs Manager   |
|     StorageFS / FUSE                           Linux tmpfs     |
|     多磁盘 / Direct / Pack                      临时缓存路径    |
|             |                                       |          |
|             v                                       v          |
|       /mnt/storage-*                      /run/profilemax/*   |
|       持久化 Profile 数据                   可丢弃缓存数据       |
+--------------------------------------------------------------+
```

职责边界：

- Admin 数据库只保存每个 Node 的 Storage Hook 配置，不保存文件、目录、inode、Pack 或 Profile 文件映射。
- Node 接收配置后，在本地完成持久化存储、tmpfs 创建、路径挂载、容量控制和恢复。
- Chromium 与 impersonate-proxy 都使用 Storage Hook 提供的路径，不允许各自绕过 Hook 写入未管理目录。
- Storage Hook 不连接 Admin 数据库，也不运行 SQLite 等数据库。
- Node 持久化元数据使用 StorageFS 自己的二进制索引、日志和快照文件；tmpfs 内容不进入持久化元数据恢复流程。

Admin 与 Node 的职责严格分离：

- Admin 数据库只保存节点 Storage Hook 的配置，不保存文件、目录、inode、Pack 或 Profile 文件映射。
- Node 接收配置后在本地执行挂载、分配、读写和恢复。
- Node Storage Hook 不连接 Admin 数据库，也不运行 SQLite 等数据库。
- Node 的本地元数据使用 StorageFS 自己的二进制索引、日志和快照文件，不将其实现成数据库服务。

## 3. Admin 配置模型

Admin 数据库只需要保存每个 Node 的 Storage Hook 配置。配置内容包括：

- 是否启用 Storage Hook。
- 统一存储根目录和元数据目录。
- 多个持久化 Volume 的标识、物理目录、容量上限、分配权重。
- tmpfs 总容量、单 Profile 上限、挂载路径规则及目录路由规则。
- Chromium 缓存目录策略与 impersonate-proxy 缓存目录策略。
- Pack 大小和小文件阈值（如果启用 Pack）。
- IO、刷盘和预留空间等运行参数。
- 配置版本号，用于 Node 热更新和回滚。

示例配置：

```json
{
    "enabled": true,
    "mount_point": "/var/lib/profilemax/storage",
    "metadata_path": "/var/lib/profilemax/storage-meta",
    "volumes": [
        {
            "id": "volume-a",
            "path": "/mnt/storage-a/profilemax",
            "capacity_gib": 500,
            "weight": 1
        },
        {
            "id": "volume-b",
            "path": "/mnt/storage-b/profilemax",
            "capacity_gib": 1000,
            "weight": 2
        }
    ],
    "tmpfs": {
        "enabled": true,
        "root": "/run/profilemax",
        "total_size_gib": 16,
        "per_profile_limit_mib": 512,
        "mode": "per-profile"
    },
    "routes": {
        "chromium_http_cache": "tmpfs",
        "chromium_rebuildable_cache": "tmpfs",
        "impersonate_proxy_cache": "persistent"
    },
    "io": {
        "pack_enabled": true,
        "small_file_threshold": 65536,
        "pack_segment_size_mib": 256,
        "read_cache_mib": 256,
        "write_batch_max_ms": 2,
        "sync_policy": "data"
    }
}
```

以上为配置结构示例。容量单位统一使用 GiB；持久化 Volume 容量上限是 StorageFS 逻辑分配上限；tmpfs 容量是内存/交换空间预算，必须单独限制，不能与磁盘容量混为一谈。路由规则必须支持按 Profile 相对路径匹配，并由 Node 在启动 Profile 前完成挂载。

以上为配置结构示例。容量单位统一使用 GiB；容量上限是 StorageFS 的逻辑分配上限，不等同于底层文件系统的硬配额。

配置下发流程：

1. Admin 保存配置并递增 config_version。
2. Node 收到配置后校验路径、权限、磁盘可用空间和配置版本。
3. Node 创建缺失目录并初始化 Volume。
4. Storage Hook 应用配置并挂载 StorageFS。
5. Node 上报实际挂载状态、Volume 可用容量和错误信息。
6. 配置变更不得直接删除已有数据；Volume 下线必须先进入迁移/只读流程。

Node 可以在本地保存一份配置快照用于重启恢复，但该文件只是配置缓存，不是数据库，也不作为配置权威来源。

## 4. Node 本地目录布局

建议：

```text
/var/lib/profilemax/
├── storage/                         # StorageFS 统一持久化挂载点
└── storage-meta/                    # StorageFS 内部元数据

/run/profilemax/
└── profiles/
    └── <profile-id>/                 # 每个 Profile 的 tmpfs 挂载目录

/mnt/storage-a/profilemax/
├── packs/
└── direct/

/mnt/storage-b/profilemax/
├── packs/
└── direct/
```

要求：

- metadata 与数据 Volume 分离，避免 Pack 写入挤占元数据日志空间。
- Pack 使用预分配或按需扩展的固定上限 Segment。
- Segment 不压缩，文件内容按原始字节存储。
- 不对每个 Profile 创建一套独立的内部数据库。
- tmpfs 由 Storage Hook 统一创建、限额、挂载和清理，不由 Chromium 或代理进程自行创建。
- tmpfs 不得覆盖整个 Profile 根目录，只挂载到明确允许丢弃的子目录。
- Profile 退出时按策略销毁该 Profile 的 tmpfs；重新启动时重新创建空缓存目录。

## 4.1 Profile 路径路由与 tmpfs 策略

Storage Hook 必须维护一份明确的路径路由规则。Profile 根目录和所有子目录仍属于 Storage Hook 的统一命名空间，但不同子目录可以映射到不同后端。

**A. 浏览器 HTTP Cache：tmpfs**

impersonate-proxy 已经缓存 HTTP 响应资源时，Chromium 本地 HTTP Cache 属于重复缓存。浏览器侧对应目录应挂载到 tmpfs，避免重复写入持久化磁盘：

- `Default/Cache/`
- Chromium 实际版本使用的 HTTP Cache 数据目录及其索引文件。

该策略只针对浏览器 HTTP 网络缓存，不代表所有网站存储都可以丢弃。

**B. 可重建缓存：tmpfs**

以下目录通常可重新生成，默认可路由到 tmpfs：

- `Default/Code Cache/`
- `GPUCache/`
- `GrShaderCache/`
- `ShaderCache/`

实际路径应根据 Chromium 版本和启动参数检测，不得依赖单一固定目录名。

**C. 必须持久化的数据**

以下数据默认留在 StorageFS 持久化后端：

- Cookies、Local Storage、IndexedDB。
- Preferences、登录态及 Profile 配置。
- Extension 数据及其状态。
- Service Worker 注册信息和 CacheStorage（除非业务明确允许清空）。
- SQLite/LevelDB 数据目录及其 WAL/SHM 文件。
- 其他无法确认可重建的 Profile 数据。

禁止将整个 `Default/`、整个 `Service Worker/` 或整个 Profile 目录直接挂载到 tmpfs。

**D. impersonate-proxy 缓存**

impersonate-proxy 的缓存目录也必须位于 Storage Hook 命名空间内，不能绕过 Hook 直接写入任意节点目录。默认将代理缓存放在持久化 StorageFS 中，以便跨 Profile/浏览器重启复用；如果代理缓存被明确配置为短期缓存，也允许由 Admin 将该目录路由到 tmpfs。

浏览器侧 HTTP Cache 与代理侧缓存是两份不同的缓存：默认保留代理侧缓存，浏览器侧重复 HTTP Cache 使用 tmpfs。两者不得误配置成同一个目录或互相覆盖。

**E. 挂载生命周期**

1. Node 启动时先挂载 StorageFS。
2. 创建 Profile 时，Storage Hook 创建该 Profile 的 tmpfs 目录并应用路径路由。
3. Chromium 与 impersonate-proxy 启动前，检查所有必需挂载均已就绪。
4. Profile 运行期间，Storage Hook 统计 tmpfs 使用量并执行硬容量限制。
5. Profile 正常停止后销毁 tmpfs；异常退出后由 Node 清理残留挂载。
6. tmpfs 满时只允许缓存写入失败或按明确策略清理可重建缓存，不得影响 Cookies、IndexedDB 等持久化数据。

## 5. 文件存储策略

StorageFS 使用 Hybrid Backend，不强制所有文件都进入 Pack。

### 5.1 Pack Backend：小文件

小文件可合并写入 Pack Segment，以减少底层 inode 数量。

Pack 记录包含：

- object_id
- segment_id
- offset
- length
- generation
- flags

元数据索引负责把虚拟文件映射到 Pack 的 offset/length。

写入流程：

1. 从内存索引查询或创建文件元数据。
2. 在当前 Segment 分配连续空间。
3. 直接写入原始数据，不压缩、不加密、不计算内容哈希。
4. 追加必要的元数据日志。
5. 更新内存索引。

读取流程：

1. 从内存索引获取 segment、offset 和 length。
2. 使用 pread/preadv 读取目标范围。
3. 尽可能使用内核 Page Cache。
4. 不经过解压、反序列化或额外的数据转换。

Pack 适合大量小型、非频繁随机修改的文件。Pack 记录更新采用新位置写入和旧记录回收，不在原位置进行复杂的碎片整理。

### 5.2 Direct Backend：活跃数据库和大文件

以下文件/目录优先使用 Direct Backend：

- SQLite 数据库及其 WAL/SHM 文件。
- LevelDB/RocksDB 等依赖文件锁和随机写入语义的目录。
- 大文件。
- 高频随机更新文件。
- 需要 mmap、fallocate 或严格 POSIX 语义的文件。

Direct Backend 由底层文件系统直接承载，StorageFS 只管理命名空间和路径映射，尽可能通过 FUSE passthrough 或等效机制减少数据面拷贝。

**不得把 SQLite、LevelDB 的活跃文件打包后再用简化接口模拟普通文件。** 如果无法完整满足锁、mmap、fsync、rename 等语义，必须使用 Direct Backend。

### 5.3 默认阈值

初始建议：

- 小于 64 KiB：允许进入 Pack。
- 大于或等于 64 KiB：Direct Backend。
- 数据库文件及其关联目录：强制 Direct Backend。
- 阈值必须可由 Admin 配置，后续通过实测调整。

Pack 不意味着所有小文件都适合打包。高频修改、频繁 truncate 的小文件也应允许强制 Direct。

## 6. IO 与 CPU 优化要求

性能目标是减少热路径开销，而不是增加复杂的存储算法。

### 6.1 禁止进入热路径的操作

- 不压缩、不解压。
- 不做内容哈希或跨 Profile 去重。
- 不进行每次读写的 JSON 序列化。
- 不在每次文件访问时访问 Admin。
- 不在每次 IO 时扫描目录或扫描 Pack。
- 不在读路径执行 GC、全量统计或容量重平衡。
- 不为每个文件启动独立任务或线程。

### 6.2 数据面优化

- 使用 Rust 实现，尽量减少不必要的内存分配和数据复制。
- 使用 FUSE low-level API，避免高层封装带来的额外开销。
- 优先评估 Linux FUSE passthrough，让 Direct Backend 的数据读写尽可能绕过用户态数据复制。
- 对 Pack 使用 pread/pwrite、preadv/pwritev 等位置 IO，避免共享文件游标锁。
- 使用有界 IO 队列和批量提交，避免无限队列导致内存增长。
- 元数据索引常驻内存，启动时通过快照和日志恢复，正常访问不查磁盘索引。
- 利用 Linux Page Cache；不要默认使用 O_DIRECT，避免绕过有效缓存。
- Segment 可预分配，降低写入时的文件扩展和碎片开销。
- 对同一 Segment 的写入采用轻量分配器，避免全局大锁。

### 6.3 元数据优化

- 使用紧凑二进制结构，不使用 JSON 存储运行时元数据。
- 目录项和 inode 元数据采用分层索引。
- inode/object ID 单调分配，避免频繁随机生成。
- 目录项查询优先走内存索引。
- 元数据日志采用 append-only 方式，减少随机更新。
- 周期性生成快照；恢复时加载快照并重放增量日志。
- 元数据日志与数据 Pack 分开存放。

## 7. 元数据与恢复机制

StorageFS 不使用数据库。

本地元数据由以下文件构成：

```text
storage-meta/
├── superblock
├── metadata.snapshot
├── metadata.wal
└── volume.state
```

- superblock：文件系统版本、UUID、配置版本和基础参数。
- metadata.snapshot：inode、目录项和对象映射的紧凑快照。
- metadata.wal：快照之后的增量元数据操作。
- volume.state：各 Volume、Segment 的分配与恢复状态。

要求：

1. WAL 记录具备长度和版本字段，能够识别尾部不完整记录。
2. 启动时先加载快照，再顺序重放 WAL。
3. 崩溃恢复不得依赖 Admin 在线。
4. WAL 达到阈值后生成新快照，再安全截断旧日志。
5. 数据写入与元数据提交必须定义明确的顺序，避免索引指向尚未落盘的数据。
6. 通过 fsync/fdatasync 提供明确的持久化语义，不得用异步写入冒充同步完成。

## 8. 多磁盘分配

Allocator 负责选择 Volume 和 Segment，不参与文件数据读写。

分配原则：

1. 只向已启用、可写且未达到容量上限的 Volume 分配。
2. 根据剩余容量、配置权重和当前 IO 压力选择 Volume。
3. 新文件/新 Pack 优先分配，不在每次读写时重新平衡。
4. 已存在的对象不因权重变化而自动搬迁。
5. 磁盘达到水位时停止新分配并上报 Admin。
6. Volume 故障时不得静默丢弃元数据或把原数据映射到其他 Volume。

初始实现使用容量权重分配即可，不引入复杂的实时全局调度算法。IO 压力指标可先用于监控，后续有实测收益再参与分配决策。

## 9. Profile 命名空间

Profile 在 StorageFS 中表现为普通目录：

```text
/var/lib/profilemax/storage/
├── profiles/
│   ├── <profile-id-1>/
│   ├── <profile-id-2>/
│   └── <profile-id-3>/
└── shared/
```

- Profile 生命周期由 ProfileMax Node 管理。
- Storage Hook 不保存 Profile 业务数据，不建立 profiles 数据库表。
- Profile 目录的 inode、目录项和对象映射属于 StorageFS 内部元数据。
- Profile 删除由 Node 调用 StorageFS 接口完成，删除过程必须支持可恢复状态，避免中途崩溃产生悬挂对象。
- 是否提供 Profile 级容量限制作为后续能力；第一阶段不增加不必要的配额索引和统计热路径。

## 10. POSIX 兼容要求

StorageFS 面向 Chromium Profile，必须重点验证：

- open / close / read / write / pread / pwrite
- mkdir / rmdir / unlink / rename
- stat / fstat / readdir
- truncate / ftruncate
- fsync / fdatasync
- flock / fcntl 文件锁
- mmap / msync
- fallocate
- hard link / symbolic link（按 Chromium 实际需求支持）

SQLite、LevelDB 等目录默认走 Direct Backend。不能完整支持的操作不得静默返回成功；必须返回正确错误，或通过 Direct Backend 提供原生语义。

## 11. 运行与管理接口

Storage Hook 作为 ProfileMax Node 的本地组件运行，不独立提供公网 API。

Node 内部接口建议：

- `Mount(config)`：初始化 Volume、StorageFS 和 tmpfs 路径规则。
- `ReloadConfig(config, version)`：应用新配置。
- `GetStatus()`：返回持久化挂载、tmpfs 挂载和 Volume 状态。
- `GetMetrics()`：返回磁盘 IO、tmpfs 使用量、容量、错误和队列指标。
- `CreateProfile(profileID)`：创建 Profile 持久化目录及对应 tmpfs 挂载。
- `GetProfilePath(profileID, category)`：向 Chromium、impersonate-proxy 返回受管路径。
- `DeleteProfile(profileID)`：停止相关进程后清理 Profile 数据及 tmpfs。
- `Flush()`：按策略刷盘；tmpfs 内容不执行持久化刷盘。
- `Unmount()`：停止接收新 IO，完成必要刷盘后卸载。

Admin 通过 ProfileMax Node 现有控制通道下发配置并读取状态，不让 Storage Hook 自己连接 Admin 数据库。

## 12. 监控指标

至少提供：

- 持久化 Volume 总容量、已分配容量、可分配容量。
- tmpfs 总容量、每 Profile 使用量、峰值和 OOM/ENOSPC 次数。
- Pack Segment 数量和利用率。
- Direct Backend 文件数量与容量。
- 按后端分类的读写吞吐量、IOPS、平均延迟、P95/P99 延迟。
- FUSE 请求数、请求排队时间。
- 元数据缓存命中率。
- WAL 大小、快照耗时和恢复耗时。
- CPU 使用率、RSS、线程数。
- IO 错误、Volume 不可用、容量不足次数。

指标采集必须低频、低开销，不允许每次文件 IO 都进行复杂统计。

## 13. 实施阶段

### Phase 1：存储路由与最小可用版本

- 先建立原生 ext4/XFS 与 tmpfs 基准。
- 实现 Storage Hook 的统一 Profile 路径入口。
- 实现持久化 Direct Backend 和 tmpfs Manager。
- 配置 Chromium HTTP Cache、Code Cache、GPU/Shader Cache 的 tmpfs 路由。
- 将 impersonate-proxy 缓存目录纳入 Storage Hook，默认持久化。
- 验证 Cookies、Local Storage、IndexedDB、Service Worker 等持久化数据不受影响。
- 验证 Chromium 与 impersonate-proxy 都无法绕过 Storage Hook 写入未管理目录。

### Phase 2：Pack Backend

- 通过基准测试确认 inode 压力是否值得引入 Pack。
- 实现小文件 Pack Segment、内存索引、追加写和随机读。
- 实现对象删除标记和后台回收。
- 增加 Direct/Pack/tmpfs 路由规则。
- 对比 Pack、Direct、tmpfs 与原生文件系统的 CPU、IO 延迟和文件数量。

### Phase 3：多 Volume

- 实现容量权重分配。
- 实现 Volume 状态检测和容量水位。
- 实现配置热更新。
- 验证单盘满载、掉盘、重启等异常场景。

### Phase 4：性能优化

- 评估 FUSE passthrough。
- 优化请求批处理、锁竞争和元数据缓存。
- 根据真实 Profile IO 负载调整 Pack 阈值和 Segment 大小。
- 只有基准数据证明有收益时才增加更复杂的缓存或调度策略。

## 14. 性能验收

所有性能测试必须与原生 ext4/XFS 目录进行对照，使用相同磁盘、挂载参数和测试数据。

测试场景：

1. 大量小文件创建、读取、删除。
2. 大量小文件随机读取。
3. 大文件顺序读写。
4. SQLite WAL 模式读写。
5. LevelDB 高频随机读写。
6. Chromium HTTP Cache 写入 tmpfs 后的启动和页面加载表现。
7. impersonate-proxy 缓存命中时，浏览器侧不再产生持久化 HTTP Cache 写入。
8. Cookies、IndexedDB、Service Worker 等持久化数据重启后完整保留。
9. 多 Profile 并发运行时 tmpfs 总量与单 Profile 限额。
10. Profile 正常退出、异常退出后的 tmpfs 清理。
11. 异常终止后的 StorageFS 恢复时间。

核心指标：

- IO 吞吐量。
- IOPS。
- P50/P95/P99 延迟。
- CPU 使用率和 CPU 时间/GB。
- RSS、tmpfs 使用量和元数据内存占用。
- 底层 inode 使用量。
- 浏览器侧重复 HTTP Cache 的持久化写入量（目标为零）。
- 崩溃恢复时间。

性能决策原则：

- 如果 FUSE 在某类 IO 上明显慢于原生文件系统，该类文件必须走 Direct Backend 或 passthrough。
- 如果 Pack 节省 inode 但显著增加 CPU 或 P99 延迟，应提高 Pack 适用门槛，而不是强制打包。
- 不以单纯减少文件数量作为成功标准；IO 性能和 CPU 开销优先。
- 不启用压缩。

## 15. 明确不做的事情

- 不使用节点数据库。
- 不把 Admin 数据库复制到 Node。
- 不做数据压缩或解压。
- 不做跨 Profile 内容去重。
- 不做内容哈希校验热路径。
- 不把所有文件强制放进 Pack。
- 不允许 Chromium 或 impersonate-proxy 绕过 Storage Hook。
- 不把整个 Profile 或未经分类的网站数据目录放进 tmpfs。
- 不在每次 IO 时请求 Admin。
- 不在第一阶段实现复杂的自动数据均衡。
- 不为了抽象而引入独立的存储集群服务。

最终交付应是一个由 ProfileMax Node 管理的本地 Storage Hook：Admin 负责配置，Node 负责执行；所有 Profile 数据统一经由 Storage Hook；持久化数据进入多磁盘 StorageFS，重复 HTTP Cache 和可重建缓存进入受限 tmpfs，impersonate-proxy 缓存也由 Hook 管理；无节点数据库、无压缩，并以 IO 性能和 CPU 效率作为主要优化方向。