WSL 2 正在获得更快的 Windows 文件系统访问

基准测试与技术说明

• 一位用户分享了在 Ryzen 7 + SSD 上的 Hugo 构建：在 WSL 的内部 ext4 VHD 上约 ~50 秒，而通过 virtiofs 访问 Windows 文件则约 ~75 秒，此外 Defender 还额外带来约 ~10 秒。他们仍然认为这比之前基于 9P 的 DrvFs 有很大改进，并且对于跨 OS 访问来说是一个“不错”的结果。
• 说明：“drvfs” 是挂载类型；它可以使用 9P（旧的、较慢）或 virtiofs（新的）。该基准测试比较的是 WSL 内部文件系统与通过 virtiofs 访问 Windows 文件，而不是 9P。
• 有人报告在升级后 WSL 启动明显更快了。

为什么文件系统性能很重要

• 普遍共识是，WSL2 访问 /mnt/c（Windows 磁盘）一直/曾经慢得令人痛苦，尤其是在处理大量小文件时（例如 node_modules、Ruby 的 require、Next.js 开发服务器、git 操作）。
• 还有几条评论提到，在 Windows 上从 WSL 删除大型 node_modules 目录树可能需要几分钟，而在原生 Windows 中只要几秒。
• 原因说法不一：有人把问题归咎于 NTFS 本身；也有人认为 NTFS 没问题，真正的成本来自 Windows 文件系统过滤驱动（Defender、AV、备份、云同步）。

virtiofs vs 9P 与限制

• 之所以使用 virtiofs 上的 9P，是因为它已经存在于 Linux 虚拟化中，而且很简单，但速度“像 NFS 一样慢”。
• 预计 virtiofs 会缩小一部分差距，但它只影响从 WSL 访问 Windows 文件。WSL 自己的 ext4 VHD 内部完成的工作仍然是最快的。
• 有人强调，即使使用 virtiofs，你仍然会碰到 Windows 侧开销（过滤器、Defender）。

开发工作流与替代方案

• 常见建议：把开发项目保留在 WSL 的 ext4 文件系统中；需要时再复制到 /mnt/c 或从那里复制回来。
• 也有人在 WSL 中挂载单独的 ext4 卷，并从 Windows 访问它们；这有时比反过来更快。
• 一些人将 WSL1 用于轻量任务（例如 SSH），因为它没有虚拟机开销，但 Docker/容器需要 WSL2。

操作系统选择、游戏与 LLMs

• 有几位表示，他们主要因为 WSL/Windows 的文件系统慢，再加上对微软云/广告整合的不满，而放弃了 Windows，转向 macOS 或 Linux。
• 反方观点：其他人认为 Windows + WSL 是非常好的开发环境，尤其是结合游戏需求，以及广泛存在的仅限 Windows 的工具（Adobe、Office/VBA、VPN、FPGA 和游戏开发工具链）。
• 关于游戏的争论：有人说 Windows 明显领先（驱动、反作弊），也有人声称现代 Linux + Proton 的性能往往与 Windows 相当甚至更好，反作弊是主要障碍。
• 多条评论表示，LLMs（Claude、ChatGPT）大大降低了迁移到 Linux 的摩擦，帮助选择发行版、配置和编写脚本。

企业与战略背景

• 很多人使用 WSL，是因为公司政策不允许裸机 Linux，但允许 Windows。
• 有人认为在这种环境下，WSL 是“接近 Linux 的唯一明智方式”。
• 少数人认为，微软本应修复 Windows 文件系统性能和 NT 方面的问题，而不是从 WSL1 的系统调用翻译转向 WSL2 的虚拟机；也有人认为，为了支持 Docker 和完整的 Linux 语义，虚拟机方案是必要的。