WSL 2 is getting faster Windows file system access

Original Article ↗ Hacker News Discussion ↗

WSL2 is gaining a new virtiofs-based mechanism for accessing the Windows filesystem, aimed at fixing long‑standing performance bottlenecks when working in `/mnt/c` from Linux. Commenters report mixed early benchmarks but broadly agree that slow file I/O, antivirus and filter overhead, and many-small-file workloads (like `node_modules`) have made WSL and Windows feel sluggish compared to native Linux. The change is seen as important for developers who must stay on Windows—often for gaming, corporate policy, or proprietary tools—but want a faster, more Linux-like development environment without fully switching operating systems.

Benchmarks and Technical Notes

  • One user shared a Hugo build on Ryzen 7 + SSD: ~50s on WSL’s internal ext4 VHD vs ~75s on Windows files via virtiofs, with ~10s extra from Defender. They still saw this as a big improvement over the previous 9P-based DrvFs and a “good” result for cross-OS access.
  • Clarification: “drvfs” is the mount type; it can use 9P (old, slow) or virtiofs (new). The benchmark compared WSL’s internal filesystem vs virtiofs access to Windows files, not 9P.
  • Some report noticeably faster WSL startup after upgrading.

Why Filesystem Performance Matters

  • Strong consensus that WSL2 access to /mnt/c (Windows drives) is/was painfully slow, especially for many small files (e.g., node_modules, Ruby requires, Next.js dev server, git operations).
  • Several note that deleting large node_modules trees from WSL on Windows can take minutes vs seconds in native Windows.
  • Explanations vary: some blame NTFS itself; others say NTFS is fine and the real cost is Windows filesystem filter drivers (Defender, AV, backup, cloud sync).

Virtiofs vs 9P and Limitations

  • 9P-over-virtio was used because it already existed in Linux virtualization and is simple, but is “NFS-like” slow.
  • virtiofs is expected to close part of the gap, but only affects access from WSL to Windows files. Work done inside WSL’s own ext4 VHD remains fastest.
  • Some emphasize that even with virtiofs, you still hit Windows-side overhead (filters, Defender).

Developer Workflows and Workarounds

  • Common advice: keep dev projects in WSL’s ext4 filesystem; copy to/from /mnt/c as needed.
  • Others mount separate ext4 volumes in WSL and access them from Windows, which can be faster than the reverse.
  • Some use WSL1 for light tasks (e.g., SSH) because it has no VM overhead, but WSL2 is needed for Docker/containers.

OS Choice, Gaming, and LLMs

  • Several report abandoning Windows for macOS or Linux primarily due to WSL/Windows filesystem slowness, along with annoyance at Microsoft’s cloud/ads integration.
  • Counterpoints: Windows + WSL is viewed by others as a very good dev environment, especially when combined with gaming needs and widespread Windows-only tools (Adobe, Office/VBA, VPNs, FPGA and game dev tooling).
  • Debate over gaming: some say Windows is clearly ahead (drivers, anti-cheat), others claim modern Linux + Proton often matches or beats Windows perf, with anti-cheat the main blocker.
  • Multiple comments say LLMs (Claude, ChatGPT) have dramatically reduced the friction of moving to Linux, helping with distro choice, configuration, and scripting.

Enterprise and Strategic Context

  • Many use WSL because corporate policy forbids bare-metal Linux but allows Windows.
  • Some see WSL as “the only sane way” to get near-Linux in such environments.
  • A few argue Microsoft should have fixed Windows filesystem performance and NT side instead of pivoting from WSL1’s syscall translation to WSL2’s VM; others think the VM approach was necessary to support Docker and full Linux semantics.