• 系统编程
• 存储
• 内核驱动

Hybrid Mount 是面向 KernelSU 与 APatch 的杂交挂载元模块，其 OverlayFS 后端支持ext4与tmpfs两种存储模式，通过配置文件中的overlay_mode一键切换。本文拆解两种存储后端的底层机制，对比性能与容量差异，并给出可直接照做的选型建议，帮助你为自己的设备挑到最合适的挂载存储方案。

一、两种存储模式从哪里来：OverlayFS 的 staging 层

Hybrid Mount 在每次开机时扫描/data/adb/modules下的模块，按「路径规则 > 模块默认值 > 全局默认值」为每一项选择 OverlayFS、Magic Mount、VFS 或忽略（详见简体中文 README）。

其中 OverlayFS 需要一个可写的staging（暂存）目录来物化 lowerdir，Hybrid Mount 为它提供了两种存储后端：

• tmpfs：暂存层完全放在内存中，速度最快；
• ext4：在数据分区上创建一个稀疏循环镜像（loop image），按磁盘速度工作。

选择权在配置文件 config.toml 中：

overlay_mode = "ext4" # ext4 | tmpfs

启动时，若配置为ext4则直接进入磁盘流程；若配置为tmpfs则优先尝试内存暂存，失败时自动回退到 ext4（见 src/storage/mod.rs 的setup_with_sources），整个存储阶段的调度位于 src/pipeline.rs。

二、tmpfs 模式：内存级速度的暂存层

挂载方式

tmpfs 模式以mode=0755参数直接挂载一块内存文件系统作为 staging（src/sys/mount.rs 的mount_tmpfs）。

硬性前提：内核必须支持 CONFIG_TMPFS_XATTR

OverlayFS 在 tmpfs 上工作依赖 xattr 支持。Hybrid Mount 会检查内核的CONFIG_TMPFS_XATTR配置项，结果只做一次并缓存（src/sys/fs.rs 的is_overlay_xattr_supported）。

自动回退逻辑

overlay_mode = "tmpfs"时的实际流程（src/storage/mod.rs 的try_setup_tmpfs）：

1. 尝试挂载 tmpfs；
2. 挂载成功但内核不支持 overlay xattr → 主动卸载 tmpfs，回退 ext4；
3. 挂载失败（如内存不足）→ 同样回退 ext4；
4. 回退前会严格确认 tmpfs 已卸载，绝不允许 ext4 挂到仍被占用的目标上（fail-closed 设计）。

📌 这意味着选择tmpfs永远不会「挂不上就卡死」——最坏情况只是退回 ext4。

三、ext4 模式：磁盘循环镜像与自动容量估算

镜像从哪来

ext4 模式下，staging 镜像固定放在/data/adb/hybrid-mount/modules.img（路径常量见 src/defs.rs）。完整流程在 src/storage/ext4.rs：

扫描内容 → 估算镜像大小 → 建稀疏文件 → mke2fs 格式化 → e2fsck 体检 → loop 挂载。

容量如何自动估算

镜像大小不是拍脑袋定的，而是按公式自动规划（planned_image_size）：

• 数据需求 = 暂存内容逻辑大小 × 1.25 + 16 MiB；
• inode 需求 = 条目数 × 1.25 × 4 KiB/个；
• 两者取较大者，最低 64 MiB，最终向上对齐到 4 MiB。

举例：100 MiB 的模块内容会规划出 144 MiB 的镜像；而 10 万个 inode 则至少需要 492 MiB。镜像是稀疏文件（set_len预分配大小），前期并不实际占用等量的磁盘空间。

格式与可靠性细节

• 使用系统自带/system/bin/mke2fs，1 KiB 块 + 4 KiB inode 密度，并关闭日志（-O ^has_journal）以换取速度，参数见 mke2fs_args；
• 大镜像自动切换 4 KiB 块，规避旧版 Androide2fsck对 1 KiB 多组镜像的检查崩溃（select_ext4_block_size）;
• 首次挂载前先用系统e2fsck体检；若首次挂载失败，自动修复 + 重试（mount_ext4_with_repair），格式化/体检均设 300 秒超时防止阻塞启动；
• 镜像会被打上u:object_r:ksu_file:s0SELinux 上下文。

sysfs 节点隐藏

ext4 staging 挂载期间，/sys下会暴露 loop 节点。KernelSU 环境使用官方NukeExt4Sysfsioctl 隐藏；APatch 等非 KSU 环境默认尝试随附的 LKM 兼容模块，支持矩阵见 module/lkm/README.md。

⏱ 开机完成后 staging 的使命就结束了：挂载被 detach，modules.img随即删除（cleanup_artifacts），不留磁盘垃圾。

四、ext4 vs tmpfs：性能、容量与启动成本对比

💡 关键点：两种模式下的 staging 都是临时的——内容每次开机都从只读的模块源目录重新物化，所以选型主要看「临时空间来自内存还是磁盘」，而非数据是否会丢。

五、选型建议：哪种模式适合你

✅ 大多数设备：保持默认overlay_mode = "ext4"。兼容面最广，不依赖内核 xattr 配置，容量由算法自动兜底，适合绝大多数模块组合。

✅ 模块多、体积大且内存充裕：改overlay_mode = "tmpfs"。大模块（如含大量文件的框架替换类模块）在 tmpfs 上物化时省去磁盘 I/O，启动更快；且即使内核不支持 xattr，也会安全回退，不会失败。

⚠️ 低端机 / 大内存敏感场景：谨慎选 tmpfs。staging 内容与 RAM 直接挂钩，模块总量越大，占用的内存越多；内存紧张时 tmpfs 挂载失败会回退 ext4，启动反而更慢。

✅ 无法确定时的验证方法：启动后执行/data/adb/modules/hybrid_mount/hybrid-mount status，查看 JSON 中的storage_mode字段——它记录本次开机实际生效的后端（tmpfs、ext4或none），而不是配置值，说明见架构文档。

六、快速上手：三步切换存储模式

1. 改配置：编辑/data/adb/hybrid-mount/config.toml，把overlay_mode设为"tmpfs"或"ext4"；
2. 重启设备：配置修改只在重启后生效；
3. 验证结果：用hybrid-mount status命令核对storage_mode是否为预期值。

升级 Hybrid Mount 时该配置文件会被完整保留，无需担心切换结果丢失。

📚 延伸阅读：docs/ARCHITECTURE.md（启动流水线与稳定路径）、docs/README_ZH.md（完整功能与配置说明）、src/storage/（tmpfs/ext4 双后端源码）。

• 系统编程
• 存储
• 内核驱动