WSL2 IO性能问题对docker的影响
WSL2 相比WSL1在各方面都有进步，使用了真实的Linux内核 。
但正因如此，在与宿主机进行文件交换的时候，就需要一个虚拟层来进行转换。而这会造成巨大的性能损失。
我们可以通过把数据目录全部放在WSL的Ubuntu分发里，来避免跨文件系统交换。
不推荐直接放在docker desktop的WSL分发里。这会带来结构混乱以及数据丢失的风险！
下面附带调查：
- 微软官方文档确证 (Microsoft Official Documentation)
微软在官方文档中明确承认在跨操作系统文件系统（Cross-OS file systems）访问场景下，WSL 2 的性能不如 WSL 1。
- 官方文章 比较 WSL 1 和 WSL 2
- 官方关键陈述：
"File performance across the Windows and Linux operating systems is faster in WSL 1 than WSL 2."
（跨 Windows 和 Linux 操作系统的文件性能在 WSL 1 中比 WSL 2 更快。） - 官方建议：
微软明确指出，如果你的项目文件必须存储在 Windows 文件系统（即 /mnt/c/ 下），建议使用 WSL 1。
- WSL 2 实测性能分析 (基于 PCIe 4.0 7000MB/s 固态硬盘假设)
即使你使用的是顶级 PCIe 4.0 SSD（顺序读写 ~7000 MB/s），在不同的挂载路径下，WSL 2 的表现会呈现出极端的两极分化。硬件的上限无法突破架构的瓶颈。
场景 A：跨文件系统读写 (访问 /mnt/c 或 Windows 挂载盘)
这是 WSL 2 的绝对性能瓶颈所在，也是不如 WSL 1 的特定场景。
- 瓶颈机制：WSL 2 是运行在 Hyper-V 虚拟机中的完整 Linux 内核。访问 Windows 文件时，必须通过 9P 协议 (Plan 9 Network Protocol) 进行网络化的文件传输。这相当于在本地进行了一次“网络挂载”。
- 顺序读写 (Sequential I/O)：
- 性能预估：尽管物理 SSD 拥有 7000 MB/s 的能力，但在 /mnt/c 中，带宽会被 9P 协议严重削减。实测通常在 200 MB/s - 1000 MB/s 之间波动（取决于文件大小和缓存命中率），远低于 SSD 的物理极限。
- 对比 WSL 1：WSL 1 使用直接的系统调用翻译层（Translation Layer）映射到 NT 内核，在此场景下直接利用 Windows 文件驱动，带宽损耗更小。
- 随机读写 (Random I/O)：
- 性能预估：毁灭性下降。由于 9P 协议的高延迟，涉及大量小文件的操作（如 git status, npm install, 编译代码）会比原生慢 10 倍甚至 100 倍。
- 具体表现：在 /mnt/c 上编译一个中型 C++ 项目可能需要数分钟，而在 WSL 2 内部文件系统中仅需数秒。在此场景下，7000 MB/s 的 SSD 与 SATA SSD 的体验差异几乎被协议延迟抹平。
场景 B：原生文件系统读写 (访问 ~/ 或 /home，即 ext4 VHDX)
这是 WSL 2 的设计优势区，也是微软推荐的使用方式。
- 机制：数据存储在虚拟硬盘文件 (ext4.vhdx) 中，Linux 内核直接管理 ext4 文件系统，绕过了 Windows NT 内核的翻译。
- 顺序读写 (Sequential I/O)：
- 性能预估：极高。可以达到物理 SSD 性能的 80% - 95%。在 7000 MB/s 的 SSD 上，WSL 2 内部可以轻松跑出 5000 MB/s - 6000 MB/s 的顺序读取速度。
- 瓶颈：主要损耗来自于虚拟化层（VHDX 文件的动态扩展开销和 Hypervisor 开销）。
- 随机读写 (Random I/O)：
- 性能预估：接近原生 Linux 水平。得益于 Linux 内核的页缓存（Page Cache）机制，小文件操作极快。
- 数据对比总结表
| 测试指标 | WSL 1 (跨 OS 访问) | WSL 2 (跨 OS 访问 /mnt/c) | WSL 2 (原生 ext4 ~/) |
|---|---|---|---|
| 架构原理 | 系统调用翻译 (Translation Layer) | 9P 协议 (网络文件系统) | 虚拟磁盘 (ext4 VHDX) |
| 顺序读写 | 高 (接近原生 Windows) | 低 (受协议带宽限制) | 极高 (接近裸机 SSD) |
| 随机 I/O | 中 (受限于翻译开销) | 极差 (高延迟，严重瓶颈) | 高 (Linux 原生缓存) |
| 元数据操作 | 中 | 极差 (如 git 扫描极慢) | 极快 |
| SSD 利用率 | 高 | 极低 (硬件性能被浪费) | 高 |
- 结论与决策建议
- 关于"不如 WSL 1"的准确界定：WSL 2 并不是全方位超越 WSL 1。在访问 Windows 文件系统（如直接在 Linux shell 中操作 C 盘下的代码库）这一特定维度上，WSL 2 的 IO 性能确实存在严重瓶颈，且显著弱于 WSL 1。
- 硬件无用论：如果你必须在 /mnt/c 下进行高强度的编译或 I/O 操作，即便升级到 PCIe 4.0 7000 MB/s 的固态硬盘，也无法解决 9P 协议带来的延迟问题。
- 正确使用姿势：为了发挥高端 SSD 的性能，必须遵循微软的架构逻辑——将代码和重 I/O 负载完全迁移到 WSL 2 的 Linux 根文件系统 (~/) 内部，仅通过 VS Code Remote 插件连接进行开发，彻底避免跨文件系统访问。