WSL 2 正在提升 Windows 文件系统访问速度

# WSL 2 正在获得更快的 Windows 文件系统访问速度 来源：https://www.boxofcables.dev/wsl2-per-device-swiotlb-pools-for-virtiofs-and-virtioproxy/ WSL（https://www.boxofcables.dev/tag/wsl-2/）从 WSL 1 的 DrvFs 到 Plan 9，再到 virtiofs，WSL 2 中的跨 OS 文件访问随着每一代更新都在不断改进。一项新的变更为每个 virtio 设备提供了专属的 DMA 池，消除了 virtiofs 路径上最后一个主要的资源争用点。 WSL 2 正在获得更快的 Windows 文件系统访问速度。如果你的工作流需要频繁跨越 Windows/Linux 边界，WSL 2 中的文件 I/O 性能一直在稳步提升。2026 年 5 月，一项[变更已合并入 WSL 2](https://github.com/microsoft/WSL/pull/40654)，它消除了 virtiofs 路径上最后几个残存瓶颈之一。要理解其重要性，不妨回顾一下跨 OS 文件访问的演进历程。 ## 我们是如何走到今天的 WSL 1（2016 年）通过 DrvFs 处理 Windows 驱动器访问——这是一个运行在 Windows NT 内核中的自定义文件系统驱动。由于 WSL 1 通过[兼容层](https://learn.microsoft.com/en-us/windows/wsl/compare-versions)直接在 Windows 内核上运行 Linux 进程，`/mnt/c` 上的文件操作几乎可以直达 NTFS。对于文件密集型工作负载，性能表现良好。 WSL 2（2019 年 5 月）将这一模式替换为[在轻量级 Hyper-V 虚拟机中运行完整 Linux 内核](https://learn.microsoft.com/en-us/windows/wsl/compare-versions#whats-new-in-wsl-2)。这是正确的取舍：真正的 Linux 内核调用、完整的系统调用兼容性，以及对 Linux 原生工作负载更好的性能。但对于跨 OS 访问，VM 边界意味着需要采用不同的方式。Microsoft 在 Windows 侧的 WSL 服务中内置了一个 [Plan 9（9P）文件服务器](https://en.wikipedia.org/wiki/9P_(protocol))。你的 Linux 会话在启动时通过 [Hyper-V socket](https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/make-integration-service) 连接到它，`/mnt/c` 上的文件操作则通过 9P 协议通道传输。 9P over Hyper-V socket 可以工作，但存在协议开销：每次操作受消息大小参数（`msize=65536`，64 KB）的限制。涉及大量小文件的工作负载在每次往返时都要承担这一开销。自 WSL 2 发布以来，Microsoft 一直在持续迭代。 2021 年前后，[virtiofs](https://virtio-fs.gitlab.io/) 作为实验性可选功能登场。Virtiofs 使用 [VirtIO](https://docs.oasis-open.org/virtio/virtio/v1.2/virtio-v1.2.html) 传输层进行共享内存文件访问，相比 9P 减少了序列化开销。你可以在 `\.wslconfig` 的 `[wsl2]` 部分通过设置 [`virtiofs=true`](https://learn.microsoft.com/en-us/windows/wsl/wsl-config) 来启用它。此后功能持续推进：[PR #40298](https://github.com/microsoft/WSL/pull/40298) 带来了设备复用改进，[PR #40426](https://github.com/microsoft/WSL/pull/40426) 在不使用 [DAX](https://docs.kernel.org/filesystems/dax.html) 的情况下增加了共享 mmap 支持，以及此次的 DMA 层修复。 ## DMA 层 Hyper-V 上的虚拟机通过弹跳缓冲区（bounce buffer）执行 I/O 的 DMA 操作——这是一段位于 4 GB DMA 边界以下、硬件可直接寻址的保留内存区域。Linux 内核将其称为 [SWIOTLB](https://docs.kernel.org/core-api/swiotlb.html) 池。在此之前，WSL 2 会话中的所有 virtio 设备共享同一个全局池。`/mnt/c` 的 virtiofs 挂载、`/mnt/d` 的挂载以及 virtio 网络适配器都在同一个缓冲区排队，在密集 I/O 时相互竞争。 [PR #40654](https://github.com/microsoft/WSL/pull/40654) 由 [Ben Hillis](https://github.com/benhillis) 编写，于 2026 年 5 月 27 日合并，为每个 virtio 设备提供了专属的 DMA 池。内核在启动时分配一段低于 4 GB 的连续物理地址范围，通过 sysfs（`/sys/bus/vmbus/drivers/hv_pci/swiotlb_base` 和 `swiotlb_size`）发布其地址，WSL 服务读取这些值并在创建每个 virtio 设备时注入各自的 `swiotlb=` 选项。驱动器与网络适配器之间不再共享队列。 **注意：** 此功能需要内核版本 Microsoft.WSL.Kernel 6.18.26.3-1，随 WSL 2 DeviceHost 1.2.29-0 一同发布。如果你使用的是较旧的内核，WSL 会提示：*"当前运行的内核缺少一个可显著提升 virtio 设备性能的补丁。请更新到更新版本的 WSL 内核以启用此优化。"* ## 实际效果 受益最大的场景是文件密集型跨 OS 工作流：在 Windows 驱动器上存放项目，但在 Linux 中进行构建。如果你将代码放在 `C:\Users\you\code` 下，然后从 `/mnt/c` 运行 `cargo build`、`npm install` 或 `mvn package`，每次文件读取都要承担跨 OS 的 I/O 开销。每设备独立的 DMA 池消除了 virtiofs 路径上残存的一个争用点。 VirtioProxy 网络同样受益，因为它共享相同的 DMA 基础设施，也获得了自己的独立池。 要充分利用这一改进： - 在 [`\.wslconfig`](https://learn.microsoft.com/en-us/windows/wsl/wsl-config) 的 `[wsl2]` 部分设置 `virtiofs=true`。 - 使用 [`wsl.exe --update --pre-release`](https://learn.microsoft.com/en-us/windows/wsl/basic-commands#update-wsl) 更新到最新 WSL 内核。 - 保持 WSL 2 会话内存在 1 GB 以上。SWIOTLB 池至少需要 64 MB 的余量。 Virtiofs 目前仍为可选功能：默认传输方式仍是 Plan 9 over Hyper-V socket。 ## 更长远的视角 跨 OS 边界的 WSL 文件系统性能随着每一代更新都在不断改善。WSL 1 的 DrvFs 之所以快，是因为不存在 VM 边界。WSL 2 引入了 VM，并转向 9P。Virtiofs 弥补了大部分差距。每设备 SWIOTLB 池消除了 DMA 层的争用。差距在持续缩小。 默认方式仍是 Plan 9 over Hyper-V socket。Virtiofs 仍为可选。相关工作正在 [github.com/microsoft/WSL](https://github.com/microsoft/WSL) 上公开推进。