虽然任何文档里都没有相关说明，但是根据 changelog 和代码提交记录，可以得知这个功能以及具体的开关。开启方法：
1. 升级到 Pre Release 版本：
wsl --update --pre-release
2. 改 .wslconfig：
[wsl2]
virtiofs=true
3. 重启 WSL：
wsl --shutdown
然后就好了
验证是否生效，在 WSL 里执行：
findmnt -T /mnt/c -o TARGET,SOURCE,FSTYPE,OPTIONS
如果 FSTYPE 的值为 virtiofs ，说明生效了
更完整的配置是：
[wsl2]
virtio=true
virtiofs=true
hostFileSystemAccess=true
如果有手动配置成 false 的配置项，可以改成 true
我今天都在用这个版本跑 AI Agent 改 NTFS 目录下的代码。原先有个项目跑单元测试要 3 分半，现在只要 1 分钟了
1. 升级到 Pre Release 版本：
wsl --update --pre-release
2. 改 .wslconfig：
[wsl2]
virtiofs=true
3. 重启 WSL：
wsl --shutdown
然后就好了
验证是否生效，在 WSL 里执行：
findmnt -T /mnt/c -o TARGET,SOURCE,FSTYPE,OPTIONS
如果 FSTYPE 的值为 virtiofs ，说明生效了
更完整的配置是：
[wsl2]
virtio=true
virtiofs=true
hostFileSystemAccess=true
如果有手动配置成 false 的配置项，可以改成 true
我今天都在用这个版本跑 AI Agent 改 NTFS 目录下的代码。原先有个项目跑单元测试要 3 分半，现在只要 1 分钟了
第 1 条附言 1 天前
我实际测试了一下性能，结果如下：
ext4 vhdx:
1) 大文件顺序吞吐
顺序写入 : 1780.9 MiB/s | 1781 IOPS | 平均时延 8.96 ms
顺序读取 : 2240.7 MiB/s | 2241 IOPS | 平均时延 7.08 ms
2) 4K 随机 I/O
读写比例 : 70% read / 30% write
随机读取 : 131.9 MiB/s | 33759 IOPS | 平均时延 696.17 us
随机写入 : 56.6 MiB/s | 14488 IOPS | 平均时延 583.29 us
3) 目录访问时延
ioping : min/avg/max/mdev = 542.8 us / 1.87 ms / 4.76 ms / 1.22 ms
9p:
1) 大文件顺序吞吐
顺序写入 : 117.9 MiB/s | 118 IOPS | 平均时延 134.74 ms
顺序读取 : 141.0 MiB/s | 141 IOPS | 平均时延 112.49 ms
2) 4K 随机 I/O
读写比例 : 70% read / 30% write
随机读取 : 12.2 MiB/s | 3131 IOPS | 平均时延 7.15 ms
随机写入 : 5.2 MiB/s | 1339 IOPS | 平均时延 7.15 ms
3) 目录访问时延
ioping : min/avg/max/mdev = 289.8 us / 336.5 us / 389.6 us / 29.4 us
virtiofs:
1) 大文件顺序吞吐
顺序写入 : 214.1 MiB/s | 214 IOPS | 平均时延 74.15 ms
顺序读取 : 239.9 MiB/s | 240 IOPS | 平均时延 66.29 ms
2) 4K 随机 I/O
读写比例 : 70% read / 30% write
随机读取 : 146.9 MiB/s | 37595 IOPS | 平均时延 599.21 us
随机写入 : 63.1 MiB/s | 16149 IOPS | 平均时延 583.33 us
3) 目录访问时延
ioping : min/avg/max/mdev = 208.5 us / 239.3 us / 281.8 us / 24.5 us
结论是：
顺序读写只比 9p 快一倍
但是 4K 随机读写比 ext4 vhdx 还要快
这意味着对于代码编译、构建的场景提升显著，而对于大量日志读写、AI 模型加载的性能提升一般
ext4 vhdx:
1) 大文件顺序吞吐
顺序写入 : 1780.9 MiB/s | 1781 IOPS | 平均时延 8.96 ms
顺序读取 : 2240.7 MiB/s | 2241 IOPS | 平均时延 7.08 ms
2) 4K 随机 I/O
读写比例 : 70% read / 30% write
随机读取 : 131.9 MiB/s | 33759 IOPS | 平均时延 696.17 us
随机写入 : 56.6 MiB/s | 14488 IOPS | 平均时延 583.29 us
3) 目录访问时延
ioping : min/avg/max/mdev = 542.8 us / 1.87 ms / 4.76 ms / 1.22 ms
9p:
1) 大文件顺序吞吐
顺序写入 : 117.9 MiB/s | 118 IOPS | 平均时延 134.74 ms
顺序读取 : 141.0 MiB/s | 141 IOPS | 平均时延 112.49 ms
2) 4K 随机 I/O
读写比例 : 70% read / 30% write
随机读取 : 12.2 MiB/s | 3131 IOPS | 平均时延 7.15 ms
随机写入 : 5.2 MiB/s | 1339 IOPS | 平均时延 7.15 ms
3) 目录访问时延
ioping : min/avg/max/mdev = 289.8 us / 336.5 us / 389.6 us / 29.4 us
virtiofs:
1) 大文件顺序吞吐
顺序写入 : 214.1 MiB/s | 214 IOPS | 平均时延 74.15 ms
顺序读取 : 239.9 MiB/s | 240 IOPS | 平均时延 66.29 ms
2) 4K 随机 I/O
读写比例 : 70% read / 30% write
随机读取 : 146.9 MiB/s | 37595 IOPS | 平均时延 599.21 us
随机写入 : 63.1 MiB/s | 16149 IOPS | 平均时延 583.33 us
3) 目录访问时延
ioping : min/avg/max/mdev = 208.5 us / 239.3 us / 281.8 us / 24.5 us
结论是：
顺序读写只比 9p 快一倍
但是 4K 随机读写比 ext4 vhdx 还要快
这意味着对于代码编译、构建的场景提升显著，而对于大量日志读写、AI 模型加载的性能提升一般
 | 1 loading 2 天前 via Android 突然想到，如果 windows 开个服务，然后走网络呢… |
 | 2 zhengfan2016 2 天前 那是不是以后不需要把代码文件移到 wsl 内部了，这个好哇  |
 | 3 YanSeven 2 天前 @zhengfan2016 我之前都是一个软链接链进去。 |
 | 4 familiar 2 天前 想起来前面微软说的今年要提升 wsl 的提升跨系统文件读写速度，优化网络等。不知道这个 virtiofs 配置是不是这个计划里面的 |
 | 5 MuyuQ 2 天前 @familiar 2026 年 3 月底 WSL 2.7.1 预发布版（ Pre-release ）正式带了大量 virtiofs 改进（包括 statx 支持、目录挂载、权限修复等），4 月份社区讨论和实际使用明显增多。 还真是微软的承诺兑现。 |
 | 6 iorilu 2 天前 不错阿, 好东西还藏着, 为什么不公开 |
 | 8 gibber 2 天前 windows10 是不是更新不了这个版本 |
 | 9 Ipsum 2 天前 via Android 以前用 windows 开发的诟病终于修了？可惜，现在主用 mac OS 了。 |
 | 10 COOOOOOde 2 天前 来晚了, 25 年已把开发机改成 macos 了, 现在只用 win 娱乐 |
 | 12 andyangyu 1 天前 我改了之后没有效果，进入一个代码目录都要卡几十秒钟 |
 | 13 Srar 1 天前 开启选项后遇到读取文件会有静默错误 |
 | 15 scegg 1 天前 好像有个问题，当外部文件发生变化时，linux 内收不到变更通知。inotify 没打通。 |
 | 16 Hephaistos 1 天前 额，别在工作机上用 Pre Release ，release 之前特性都可能删的 |
 | 17 javalaw2010 1 天前 虽然但是，ntfs 和 ext4 文件系统不一致还是有可能导致问题的，ntfs 默认大小写不敏感，虽然有办法开启大小写敏感，但是我想大部分人创建项目的时候应该不会记得这个步骤。。。但至少是迈出了这一步吧 |
 | 18 WispZhan 1 天前 |
 | 19 artiga033 1 天前 via Android 看起来不错，但是我已经没有跨文件系统大量随机读写的需求了。需要在 win 侧跑的代码都是和 Windows 强相关的，linux 下也跑不了；别的代码全放 wsl 侧也挺好，毕竟某些语言天生就看不起 Windows 呢( |
 | 20 paranoiagu 1 天前 这么操作一下，原来的数据还在的吧。 |
 | 21 ShadowPower OP @paranoiagu 都在，能正常使用 |
| 22 paranoiagu 1 天前 @ShadowPower 谢谢。那我也来搞一下 |
| 23 paranoiagu 1 天前 你们都文档吗？我刚试了一下。想把虚拟硬盘的数据 mv 到物理硬盘，结果一顿报错。移回来，更加报错。 移过去： [磁盘空间肯定有的] mv: error writing 'xxxxxxxxxxxxxxxxxxx': No space left on device 移回来： mv: error writing 'xxxxxxxxxxxxxx': Bad address |
 | 24 INCerry 1 天前 开启后我遇到了一个问题，会导致虚拟机 hang 死无法结束进程，只能重启。 |
 | 25 ssshn115 1 天前 已升级还没测试。 发现个问题，原本在 wsl2 运行的容器挂载的是 windows 目录，现在无法启动了，已经把挂载目录迁移到 wsl 内部了。 |
 | 26 Jack66 1 天前 我也明显感受快，虽然没测，代码都在 wsl |
 | 27 guoxu1231 1 天前 要我说就别折腾 windows 相关开发环境了， 全部 wsl2 或者 macos |
 | 28 stimw 1 天前 做渲染相关的梭哈 wsl 肯定是不方便的，只能虚拟机。 |
 | 29 fcymk2 1 天前 还是比开个 samba 的慢 |
 | 30 m290236573 1 天前 Codex crashed with the following error: (code=139, signal=null). Most recent error: None, 改完之后 codex 打不开了 |
 | 33 jackmod 1 天前 win 环境的工程文件都放在 refs （ dev drive ）里，比 ntfs 稍微好点 |
| 34 paranoiagu 1 天前 via Android 悠着点♂ |
Select Language