虽然任何文档里都没有相关说明，但是根据 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 条附言 · 2 天前
我实际测试了一下性能，结果如下：
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 2 天前
我改了之后没有效果，进入一个代码目录都要卡几十秒钟
|
 |
13
Srar 2 天前
开启选项后遇到读取文件会有静默错误
|
 |
15
scegg 2 天前
好像有个问题，当外部文件发生变化时，linux 内收不到变更通知。inotify 没打通。
|
 |
16
Hephaistos 2 天前
额，别在工作机上用 Pre Release ，release 之前特性都可能删的
|
 |
17
javalaw2010 2 天前
虽然但是，ntfs 和 ext4 文件系统不一致还是有可能导致问题的，ntfs 默认大小写不敏感，虽然有办法开启大小写敏感，但是我想大部分人创建项目的时候应该不会记得这个步骤。。。但至少是迈出了这一步吧
|
 |
18
WispZhan 2 天前
|
 |
19
artiga033 2 天前 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