WSL 2 的文件访问性能优化经历了一个漫长的技术迭代过程。最初的 WSL 1(2016)使用 DrvFs,这是一种直接运行在 Windows NT 内核上的自定义文件系统驱动,使/mnt/c下的文件操作几乎直接到达 NTFS,延迟极低。WSL 2(2019)切换到完整 Linux 内核运行在轻量级 Hyper-V VM 中后,跨系统文件访问面临新的技术挑战——微软在 Windows 端 WSL 服务中构建了一个 Plan 9 文件服务器,Linux 会话在启动时通过 Hyper-V socket 连接,9P 协议成为了两者之间的桥梁。
问题在于 9P 协议有固有缺陷:每次操作的消息大小被限制在 64 KB 参数以内,对于文件 heavy 的工作负载——比如涉及大量小文件的操作——会产生显著的开销。2021 年左右,virtiofs 作为实验性功能登场,用户可以通过在 .wslconfig 文件的 [wsl2] 部分设置 virtiofs=true 来启用。virtiofs 使用 VirtIO 传输进行共享内存文件访问,相比 9P 减少了序列化开销。但它一直是 opt-in 的可选功能——默认传输仍然是 Plan 9 over Hyper-V socket。
2026 年 5 月,一个重要的变化通过 PR #40654 合并到 WSL 2 主线。这个由 Ben Hillis 编写的变更,为每个 virtio 设备提供了独立的 DMA 池,而不是共享一个全局 SWIOTLB 池。在此之前,WSL 2 会话中的所有 virtio 设备——包括不同驱动器的 virtiofs 挂载点和 virtio 网络适配器——都在同一个 bounce buffer 区域(下限 4GB DMA 边界)排队,在重 I/O 操作期间造成争用。对于同时使用多个驱动器挂载点的用户,这个争用尤为明显。

这个优化需要 Microsoft.WSL.Kernel 6.18.26.3-1 或更高版本,结合 WSL 2 DeviceHost 1.2.29-0 使用。运行旧内核的用户会看到一条消息:"The running kernel is missing a patch that significantly improves virtio device performance. Update to a more recent WSL kernel to enable this optimization." 这是一个非破坏性的变更——没有独立 DMA 池功能的系统仍然可以正常运行 virtiofs,只是无法享受性能优化。
受益最大的场景是跨系统文件 heavy 的工作流:项目存储在 Windows 驱动器上,但构建在 Linux 中运行。从 /mnt/c 执行 cargo build、npm install 或 mvn package 等命令,都会因这个优化而改善性能。VirtioProxy 网络也受益,因为它共享同一个 DMA 基础设施。用户应当确保 WSL 2 会话的 RAM 保持在 1GB 以上,以提供至少 64MB 的 SWIOTLB 池空间余量——这是让优化生效的前提条件。
virtiofs 仍然是 opt-in 的默认选项。对于大多数用户,这意味着如果当前 virtiofs 没有打开,这个优化暂时还与你无关。但它代表了 WSL 2 在文件访问性能这个议题上持续改进的路径——微软正在逐步解决过去几年社区反馈最多的痛点之一。
参考来源:https://www.boxofcables.dev/wsl2-per-device-swiotlb-pools-for-virtiofs-and-virtioproxy/