WSL 存储扩容与 ext4 数据盘落地：从 DrvFs 卡顿到 data-4tb.vhdx 挂载方案1. 背景与目标 这次折腾 WSL 存储，不是从“磁盘空间不够”开始的，而是从一个更具体的运行时症状开始的：StaticFlow 的音乐库和内容库最初都放在 /mnt/e/static-flow-data这个路径在 WSL 里对应的是 Windows E: 盘，经由 DrvFs / 9p 暴露给 Linux在后台 compaction 运行时，歌曲读取、音频 blob 访问这类操作会出现明显卡顿，甚至表现为“像卡死一样” 问题的关键不只是“性能慢”，而是数据库和大对象读写都在依赖一层并不等价于 Linux 原生 ext4 的文件系统语义。对于 LanceDB 这种带 manifest、fragment、blob、compaction、rename 和 metadata 交互的工作负载，这种差异会直接影响稳定性。 这次落地目标最终收敛成了四条：让 StaticFlow 的数据库路径脱离 /mnt/e 这类 DrvFs 路径。不动现有 Ubuntu 的系统盘 D:\wsl_ubuntu\ext4.vhdx。数据物理上仍然放在 E:，避免继续挤压当前发行版根盘。在 WSL 内部获得真正的 ext4 语义，而不是“看起来像本地盘”的 Windows 映射目录。2. 模型与术语 为了避免后面概念混淆，这里先固定几个术语。2.1 发行版根盘 发行版根盘是 Ubuntu 自己的那块系统盘，在这台机器上对应：Windows 文件：D:\wsl_ubuntu\ext4.vhdxWSL 内部挂载：/文件系统类型：ext4 这是 WSL 发行版本体所在的磁盘。/home、/var、/srv 这些路径都属于这块盘。2.2 DrvFs 路径 DrvFs 路径指的是：/mnt/c/mnt/d/mnt/e 这些路径的底层不是 Linux 本地 ext4，而是 Windows 文件系统通过 WSL 做的映射层。对普通源码目录、文档、共享文件来说它们很方便，但对数据库负载来说不是理想选择。2.3 数据 VHDX 数据 VHDX 指的是新建的独立虚拟磁盘文件：E:\wsl-disks\data-4tb.vhdx 它的物理文件位于 E:，但挂入 WSL 之后会被格式化成独立的 ext4 文件系统，供业务数据使用。2.4 业务数据根 最终业务使用的目录不是整块挂载盘根目录，而是这块盘下专门给业务准备的子目录：/mnt/wsl/data4tb/static-flow-data 这个目录由 ts_user 持有写权限，StaticFlow 后端最终指向这里。3. 故障现象与约束条件3.1 运行时症状 前期最明显的问题是：后台 compaction 运行时，歌曲读取请求变慢get_song_audio() 这类读取 blob 的路径，和 compaction 同时打到 /mnt/e 时更容易出现“长期挂住”的观感当前代码里并没有给 songs 表加应用层 shared/exclusive 锁，所以更像底层 IO 竞争，而不是新业务锁逻辑造成的阻塞 这个判断和存储层现状是一致的：/mnt/e/static-flow-data 不是 ext4它走的是 Windows E: 盘的 DrvFs/9p 映射compaction 与 blob 读同时压这层映射时，更容易暴露吞吐下降和延迟拉长3.2 容量约束 排查过程中又遇到了第二个现实条件：当前 Ubuntu 根盘虽然是 ext4，但可用空间已经偏紧根盘的 VHDX 大小约为 1TB 级别，而不是预期中的 2TB即使 WSL 2.6.1 已支持 wsl --manage Ubuntu --resize 2TB，直接动现有根盘仍然不是风险最小的方案 也就是说，单纯把 StaticFlow 数据迁到 /srv/staticflow-data 这种发行版根盘路径，在概念上最简单，但在这台机器当前容量条件下并不合适。3.3 运维边界 这次方案还受几个明确边界约束：不改动已有系统盘 D:\wsl_ubuntu\ext4.vhdx不对现有 E: 盘原地重格式化不做双根盘或 RAID 根盘这类维护成本高的结构尽量保留“数据仍在 E 盘”的运维心智4. 方案比较与决策依据 在真正落地之前，评估过几种可行路径。 | 方案 | 优点 | 主要问题 | 结论 | |---|---|---|---| | 继续使用 /mnt/e/static-flow-data | 不迁移，最省事 | DrvFs/9p 语义不适合数据库，compaction 与 blob 读写风险持续存在 | 不采用 | | 直接迁到发行版根盘 /srv/... | 真正 ext4，最原生…