HN Debrief

WSL 2 is getting faster Windows file system access

  • Developer Tools
  • Infrastructure
  • Programming
  • Open Source
  • Enterprise IT

The post explains an upcoming WSL 2 storage change that targets a long-standing problem: Linux processes running in WSL are much slower when they read and write files on the Windows filesystem than when they stay inside WSL’s own virtual disk. The old cross-boundary path used a Plan 9 based file server. The new one uses virtiofs plus related kernel work, which should cut a lot of the translation overhead. That matters most for developer workloads with huge numbers of small files, like npm installs, Git operations, compiles, and web app hot reloads. Several people called out /mnt/c specifically, since many developers either do not know it is the slow path or keep using it because they need the files visible to Windows tools.

If your team develops on Windows with WSL, this update could remove a major source of pain for Node, Git, compilers, and anything that thrashes lots of small files on mounted Windows drives. It does not remove the need to choose where code lives, and it definitely does not solve the broader policy, update, and endpoint-control issues pushing some developers to Linux or Mac.

Discussion mood

Positive about the specific WSL change, frustrated about how long it took, and broadly sour on Windows as a developer desktop. The strongest complaints were about slow small-file workloads, antivirus and corporate security overhead, forced cloud and advertising features, and the need to keep juggling files between the Windows side and the WSL side.

Key insights

  1. 01

    Why small-file workloads feel awful

    The real pain is not bulk throughput. It is per-file overhead. When WSL touches files under /mnt/c, each open, read, and metadata lookup crosses a translation layer into Windows. That makes Node, Git, Ruby, and build tools crawl because they hit tens of thousands of tiny files. Keeping code inside WSL’s own virtual disk avoids most of that, which is why the old rule of thumb was to copy projects into $HOME and only sync back when needed.

    Audit where your repos actually live before blaming WSL broadly. If a workflow still depends on mounted Windows paths, expect this update to help a lot more than workloads already kept inside the WSL disk.

      Attribution:
    • omcnoe #1
    • tonymet #1
    • torginus #1
  2. 02

    Windows security hooks are part of the bottleneck

    Several comments pinned the slowdown on Windows file-system filter drivers and real-time scanning, not just on the shared-files protocol. Antivirus, endpoint controls, and corporate security agents sit on every file operation and multiply the cost of small-file development workloads. That explains why node_modules can be miserable on native Windows, WSL, and even Docker on Windows at the same time. It also explains why Dev Drive exists and why some people see huge improvements by changing security settings rather than changing code.

    If your developers are on managed Windows machines, benchmark with endpoint tools in the loop. A WSL upgrade may help, but corporate security software can still dominate the profile and wipe out most of the gain.

      Attribution:
    • 0x1d7 #1 #2
    • rahkiin #1
    • beart #1
  3. 03

    WSL2 exists because WSL1 hit a ceiling

    The cleaner architecture was WSL1. It translated Linux syscalls directly on top of NT and had very low overhead. But comments pointed out that Docker and full container support were the showstopper. WSL2’s VM design was the pragmatic choice because it gives Windows a real Linux kernel and compatibility surface without reimplementing container behavior inside NT. The cost was exactly the awkward split people still feel today between the fast Linux filesystem and the slower Windows one.

    Do not read this upgrade as Microsoft inching back toward a pure syscall-translation model. The strategic bet is still a Linux VM with better plumbing around it, so plan workflows around that architecture.

      Attribution:
    • josh3736 #1
    • bitwize #1 #2
  4. 04

    WSL survives because enterprises need both worlds

    The strongest defense of WSL was not technical elegance. It was organizational reality. Many teams cannot run bare-metal Linux at work, yet still need Linux shells, containers, SSH, and package ecosystems. At the same time they depend on Windows-only software, internal corporate apps, locked-down VPN tooling, Office macros, Adobe tools, Unreal, FPGA stacks, or security controls. In that environment WSL is the least bad compromise, and filesystem improvements matter because they reduce the tax on a setup companies are unlikely to abandon.

    If you lead an enterprise dev environment, assume WSL will remain strategically relevant as long as Windows-only business software does. Improvements here can pay back quickly because they affect a captive user base, not just enthusiasts.

      Attribution:
    • hiAndrewQuinn #1
    • epolanski #1
    • bel8 #1
    • beart #1
  5. 05

    LLMs are lowering the cost of leaving Windows

    A separate but telling thread said AI assistants now make Linux migration much easier. People described using Claude or ChatGPT to pick a distro, edit configs, write setup scripts, and navigate the usual distro-specific rabbit holes that used to keep them on Windows. The interesting point was not that Linux got simpler on its own. It was that open systems are easier for an agent to inspect and modify end to end. That makes desktop Linux more approachable at exactly the moment Windows is frustrating developers in other ways.

    Do not assume developer OS inertia is as sticky as it was a few years ago. If Windows remains annoying while AI assistants keep collapsing Linux setup friction, migration pressure can rise faster than old adoption models suggest.

      Attribution:
    • phowat #1
    • ragequittah #1
    • 2001zhaozhao #1

Against the grain

  1. 01

    Many users never hit this bottleneck

    For some setups this is close to a non-issue. People using WSL mainly for containers, SSH, or small builds said they do not notice slow file access at all. If code already lives in the WSL filesystem, or if Windows is only the host shell around Linux tools, the infamous /mnt/c slowdown barely enters the picture.

    Do not universalize the horror stories. Measure your own workload mix first, because teams centered on containers or in-VM files may see little practical benefit from this change.

      Attribution:
    • tonymet #1
    • p-t #1
    • pjmlp #1
  2. 02

    Linux desktop still has its own rough edges

    Not everyone accepted the implied conclusion that Windows is uniquely broken for developers. One detailed reply argued that Linux desktop still falls down under memory pressure, can freeze in less recoverable ways, and often demands obscure escape hatches like switching to a TTY. From that view, WSL on a sane Windows install is already a better compromise than daily-driving Linux for many people.

    If you are considering standardizing on Linux desktops, separate dissatisfaction with Windows policy from the actual operational quality of Linux on your hardware. WSL may still be the lower-risk choice for some orgs.

      Attribution:
    • IshKebab #1 #2
  3. 03

    This only helps cross-filesystem workflows

    The improvement is narrower than the headline makes it sound. It speeds access from WSL2 into Windows-hosted files. It does not make WSL’s own ext4 disk faster, and it does not matter much if you already keep your dev environment entirely inside WSL. People who learned that habit years ago may see only marginal changes.

    Position this internally as a fix for mixed Windows plus Linux file access, not as a blanket WSL acceleration. Otherwise you will create expectations that the update cannot meet.

      Attribution:
    • jstrebel #1
    • weird-eye-issue #1

In plain english

Dev Drive ↩
A Windows storage configuration designed to improve developer workloads by reducing some file scanning overhead.
Docker ↩
A platform for packaging and running software in isolated containers so it behaves consistently across environments.
ext4 ↩
A widely used Linux filesystem in the ext family that adds journaling and other features to reduce corruption and improve recovery.
FPGA ↩
Field-programmable gate array, a reconfigurable chip that can be programmed for custom hardware logic.
Git ↩
A version control system developers use to track code changes and switch between branches of a project.
node_modules ↩
The directory where npm stores a project’s many dependency packages, often containing huge numbers of small files.
npm ↩
The default package registry and package manager commonly used for JavaScript and Node.js projects.
NTFS ↩
New Technology File System, the main filesystem used by Windows for storing files on disk.
Plan 9 ↩
A research operating system from Bell Labs whose file-sharing protocol, often called 9P, is used in some virtualization setups.
PowerBI ↩
A Microsoft business intelligence and dashboard product used for reporting and analytics.
SSH ↩
Secure Shell, a standard tool and protocol for securely logging into and managing remote computers.
TTY ↩
A text-only terminal session that can be used directly without the graphical desktop.
virtiofs ↩
A shared file system mechanism for virtual machines that lets a guest access host files with lower overhead than older methods.
WSL ↩
Windows Subsystem for Linux, a Microsoft feature that runs Linux environments inside Windows.
WSL 2 ↩
The newer WSL architecture that runs a real Linux kernel inside a lightweight virtual machine.

Reference links

WSL and virtualization references

  • Windows Terminal
    Suggested as a better terminal host for WSL than Command Prompt or PowerShell when dealing with keyboard and paste behavior.
  • Benchmark gist for WSL virtiofs test
    Shared as the script used to benchmark compile times under different WSL filesystem setups.

Linux gaming and compatibility tools

  • Proton
    Linked to clarify that Proton is Valve’s compatibility layer for running Windows games on Linux.
  • ProtonDB
    Recommended as the practical source for game-specific Linux compatibility tips and fixes.
  • Nobara Project
    Offered as a preconfigured Fedora-based distro aimed at making Linux gaming easier out of the box.
  • Gamescope
    Mentioned as Valve’s game-focused Wayland compositor and wrapper in a side discussion about Linux graphics stacks.

Background and related controversy