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/