Fixing Slow File I/O When Working on /mnt/c from WSL2

Slow file operations specifically when working with files under /mnt/c/... from inside WSL2 — while the exact same kind of workload feels fast on the Linux-native filesystem — is an expected consequence of how WSL2 bridges the two filesystems, not a misconfiguration.

Step 1: confirm the slowdown is specifically tied to /mnt/c access

time ls -la /mnt/c/Users/name/project
time ls -la ~/project

If operations against a Linux-native path are noticeably faster than the identical operation against the same data under /mnt/c, you’ve confirmed this specific, well-understood cross-filesystem overhead rather than a general performance problem.

Step 2: understand why this overhead exists

Every file operation crossing from Linux into /mnt/c goes through a 9P protocol bridge to the Windows host’s NTFS filesystem, translating between different filesystem semantics on each individual operation — for workloads doing large numbers of small file operations (node_modules installs, compiling many small source files), this per-operation overhead compounds significantly.

Step 3: move the project to the Linux-native filesystem

cp -r /mnt/c/Users/name/project ~/project
cd ~/project

This is the actual, structural fix, not a workaround — moving a project you’re actively building or running from Linux-side tools onto the native ext4 filesystem eliminates the cross-filesystem overhead entirely for every subsequent operation.

Step 4: access the project from Windows-side tools via the network path if still needed occasionally

\\wsl$\Ubuntu\home\username\project

If you occasionally still need to open specific files from a Windows-side editor or tool, accessing the Linux-native filesystem via this network path works fine for occasional access — the performance concern specifically applies to sustained, intensive I/O, not occasional individual file opens.

Step 5: reconfigure your development tools to point at the new location

# update any editor workspace configs, environment variables,
# or build scripts referencing the old /mnt/c path

Moving the actual files is only half the fix — anything hardcoded to reference the old /mnt/c path (editor recent-projects lists, environment variables, CI configuration) needs updating too.

Step 6: verify the performance improvement directly

time npm install
# compare timing before and after the move

Running the same representative operation (a package install, a build) before and after the move quantifies the actual improvement, rather than relying on a subjective “it feels faster” impression.

Step 7: understand when /mnt/c access is genuinely fine to keep using

Occasional, low-frequency access to Windows-side files — reading a single configuration file, writing an occasional log — doesn’t hit this overhead meaningfully, since the cost scales with operation count, not with the mere existence of a cross-filesystem boundary. The fix specifically matters for high-frequency, intensive I/O workloads.

Why this isn’t something WSL2 can simply optimize away

The 9P bridge exists specifically because Linux and Windows filesystems have genuinely different underlying semantics that must be translated at the protocol level — no amount of caching or optimization fully eliminates this overhead for sustained, intensive cross-filesystem I/O, which is exactly why Microsoft’s own guidance is to keep actively-used project files on the filesystem matching whichever OS’s tools you’re using most.