M2 做完了：files 分区能自动扩大，也能在使用中缩小；新的 VFS 模块把所有文件访问统一起来，可以热替换；用户态进程有了文件系统调用和 execve。2026.10.25.3 已发布并部署到两台机器。下一个里程碑 M3 需要你确认后再开始，另有四个评估结论等你决定。
| 步骤 | 内容 | 验证 |
|---|---|---|
| M2.1 | ext4 原地扩大：新块组的元数据先写好，描述符和超级块作为一次日志事务提交 | 单元测试；e2fsck 检查扩大后的镜像 |
| M2.2 | files 分区的规则：从 1 GiB 开始，结束在下一个整 GiB 之前；剩余少于十分之一或 100 MiB、或者写不下时自动加长一步；可以关掉自动扩大；控制台 files grow [max] | files_grow_test：150 MiB 的分区按规则扩大，文件都在，e2fsck 干净 |
| M2.3 | 在使用中缩小（files shrink <MiB>）：主循环空闲时一小步一小步地搬块、给 inode 换号、切掉块组，最后改短分区；日志在新结尾之后时先搬到前面（这部分是你写的），新做的日志放在最前面 | 2175 MiB 缩到 1024 MiB，其间照常上传和读取；断电测试；e2fsck |
| M2.4 | VFS 模块：挂载表、路径查找（符号链接、..、挂载点、调用者自己的根目录）、打开的文件、名字缓存、权限位；删除时仍打开的文件保留到最后一次关闭；热替换时交接挂载和打开的文件。文件系统驱动改为按 inode 工作，应用的文件调用全部经过 VFS | 8 个单元测试（真实 ext4 驱动跑在内存盘上）；hot_test 在下载过程中替换 vfs 和 ext4 |
| M2.5 | 进程的文件系统调用：open、read/write、stat 一族、getdents64、dup/fcntl、mkdir/unlink/rename/link/symlink 及 *at 形式、chmod/chown、truncate、chdir/getcwd/chroot、umask，以及从文件加载程序的 execve。描述符表、根目录、工作目录在内核的进程表里，fork 时共享，进程结束时关闭 | tests/user/filetest 66 项检查全部通过 |
| M2.6 | 热替换和断电：一个进程打开着已删除的文件时，依次替换 vfs、ext4、linux 三个模块，进程照常读写；打开着已删除的文件时断电，下次启动释放它 | file_test；e2fsck 干净 |
| M2.7 | 评估（只评估，不改代码），见下文 | 文档 docs/m2-evaluation.md |
| M2.8 | 收尾：ext4 按路径的整文件调用只剩测试在用，移进测试专用的文件 | 全套测试通过 |
| 机器 | 做了什么 | 结果 |
|---|---|---|
| rustros.com | 发布 2026.10.25.3（内核、全部模块、镜像、签名清单）；报告改放在 rustros.com/reports/，源文件在 git 的 site/reports/ | 清单里有 vfs，ext4 写明需要 vfs |
| 阿里云 | 新内核试启动并确认（slot b）；先装 vfs、ext4（这台以前没装，这次也装上，19 GiB 的 files 分区挂上了），再装其余模块和 netstack、linux，重启一次 | 全部运行，没有崩溃记录 |
| 第二台生产机 | 同样的步骤，vfs、ext4、sites 最先装 | rustros.com 首页、发布页、报告页、清单都是 200 |
| 问题 | 影响 | 打算 |
|---|---|---|
| sites 上传 60 MiB 的文件会被断开（20 MiB 正常） | 大文件上传不了；可能是整个请求体放在内存里 | 上传改为边收边写进文件 |
| info 里 linux 模块显示“not running” | 只是显示：系统调用模块在状态列表里没有条目，实际已启动 | 补上状态条目 |
| 开机时 ext4 比 vfs 先启动 | 日志里先出现一条“vfs 没装”的提示，随后 vfs 挂上；分区还多卸下、挂上一次 | 开机阶段不报这条提示；查清多出的一次重新挂载 |
| 64 B 转发在嵌套测试机上波动大 | 单流三次是 371、324、302 kpps；测试机上同时有别的负载时发包端也变慢 | 包路径的代码在 M2 没有改动；需要时在空闲时段单独复测 |
| 进程还不能映射文件、运行 #! 脚本，没有管道、信号、终端 | 动态链接的程序和 shell 脚本还跑不了 | M3 兼容层、M5 终端 |
按已确认的顺序，下一个是 M3：让容器里的程序需要的系统调用跑起来（文件映射 mmap、管道、信号、poll/epoll、时间和睡眠、进程组等），先能跑 Debian 的静态和动态链接程序（ld.so、glibc），用 LTP 和观察到的行为验证；之后是 M4 网络系统调用。
1. 上面四个评估结论各怎么定（特别是 TLS 共享模块要不要在 M3 之前先做）。
2. M3 的范围是否合适；确认后我再开始 M3。