WSL, Dev Drive, and Filesystem Placement: Choosing Performance Without Losing Interop

Where you physically place a project’s files — inside WSL 2’s own virtual ext4 disk, on an ordinary NTFS Windows volume reached through DrvFs, or on a Dev Drive formatted with ReFS — has a real, measurable effect on build and tooling performance, and the three options aren’t interchangeable trade-offs of the same underlying thing. Each was built with a different primary workload in mind.

Why metadata-heavy Linux workloads favor the native ext4 disk

Compilers, package managers, and version control systems perform an enormous number of small metadata operations — creating, stating, renaming, and deleting many small files in rapid succession, exactly the pattern a git status, an npm install, or an incremental compile generates. WSL 2’s own virtual disk, formatted as ext4 and accessed natively by the Linux kernel running inside the utility VM, handles this pattern with native Linux filesystem semantics and without crossing any cross-OS translation boundary. For Linux toolchains working on Linux-native project files, this is consistently the fastest option WSL offers.

Why crossing into /mnt costs something real

Windows tools reach a WSL distribution’s filesystem through \\wsl.localhost\<Distro>\, and conversely, WSL reaches Windows drives through /mnt/c and similar mount points backed by DrvFs, the driver translating between Linux’s filesystem expectations and the underlying NTFS volume. Every one of those metadata-heavy operations, run against a project living under /mnt/c, now crosses this translation layer — file stats, permission checks, and directory operations each pay a cost that a purely native ext4 operation doesn’t. This is precisely why a large Node.js or Python project with tens of thousands of small files can feel noticeably slower to build when placed under /mnt/c than when placed inside the distribution’s own native filesystem, even though the underlying disk hardware is identical either way.

Dev Drive: ReFS retuned specifically for developer patterns

Announced by the Windows team at Microsoft Build 2023, Dev Drive is a storage volume built on ReFS (Resilient File System) but specifically retuned for developer workloads rather than ReFS’s original data-integrity-and-scale focus — Microsoft describes optimizing metadata handling, directory operations, and allocation patterns for exactly the repository-clone, package-cache, and incremental-build-output patterns that dominate real development work. Combined with Microsoft Defender’s performance mode capability for trusted developer directories, Microsoft reported build-time improvements up to roughly 30% compared to then-current Windows 11 22H2, with per-operation improvements in the 22–41% range depending on the specific tool and operation measured.

What Dev Drive does not do

Dev Drive is a genuine Windows-side performance improvement for Windows-facing developer workflows — it does not convert DrvFs into ext4, and it does not make a project stored on a Dev Drive perform identically to the same project stored natively inside WSL’s own ext4 disk when accessed from Linux tooling. A build running from inside WSL, targeting files that still live on a Dev Drive volume reached through DrvFs, still crosses the same cross-OS translation boundary Dev Drive doesn’t eliminate — Dev Drive’s performance gains are demonstrated for Windows-native tools operating directly on that volume, not for the WSL-to-Windows-volume access pattern specifically.

Choosing based on which side actually does the work

The practical decision comes down to which environment is doing the heavy lifting for a given project: a Linux toolchain (a Go, Rust, or Python build running entirely inside WSL) is best served by keeping the project inside the distribution’s own native filesystem. A Windows-native toolchain, or a workflow genuinely split between Windows tools (a Windows-only IDE or build step) and Linux tools needing to reach the same files, is where Dev Drive’s Windows-side performance improvements are actually relevant, since the Windows-side operations are what Dev Drive was built to accelerate.

Benchmark your actual workload rather than assuming

General guidance about which filesystem is faster only goes so far — the honest answer depends on your specific compiler, package manager, project size, and whether you’re measuring cold-cache or warm-cache performance. Time a representative build or test suite run in each candidate location before committing to a project layout, rather than relying on someone else’s benchmark from a different toolchain and project shape. A simple, repeatable comparison — clean checkout, cold-cache full build, then a small incremental change and rebuild, timed in each candidate location — usually surfaces a clear enough difference to make the decision obvious for your specific project, without needing a more elaborate benchmarking setup than a stopwatch and a consistent test script.

Where container engines fit into this choice

Docker Desktop and similar container tooling add a fourth consideration: container image layers and volumes have their own storage location, typically inside WSL 2’s own managed disk regardless of where a project’s source files happen to live. A slow container build is frequently a symptom of the build context being read from a /mnt-backed location rather than the container storage itself being slow — checking where the Dockerfile’s build context actually lives is worth doing before assuming the container runtime itself is the bottleneck.

Avoid splitting one project across two access patterns

A specific, easy-to-fall-into mistake is having the same Git working tree accessed both from native Linux tools inside WSL and from Windows-native tools expecting a different case-sensitivity or line-ending convention simultaneously. Pick one authoritative location and access pattern for a given project, and treat any secondary access as read-only or through an explicit sync step, rather than letting two toolchains independently write to the same tree through fundamentally different filesystem semantics. Related: Fixing Slow File I/O When Working on /mnt/c from WSL2 · Fixing High vmmem Memory Usage in WSL2

Sources: