WSL2 Is Not Slow; The Boundary Is: A 300-File Test That Finds Your /mnt/c Tax

A post published on dev.to takes the most common WSL2 complaint, that `cp` crawls and `npm install` takes forever while the identical command one directory over is instant, and reframes it as a measurement error rather than a performance defect [s1c1]. The claim worth operators' attention is the shape of the cost: it is paid per crossing of the Windows/Linux filesystem boundary, which makes the fix architectural (move the working tree) rather than a mount option you forgot to set [s1c2].

The author's headline number: creating 300 small files on the Windows side took an order of magnitude longer than the identical work on the Linux side [s1c3]. The same asymmetry shows up in aggregate shape. Handle the same 1GB as one large file or as 1,000 small files and the many-small-files case can lose by an order of magnitude, even though total bytes moved are identical [s1c4].

Microsoft's own documentation states the rule without explaining it: unless you have a specific reason to cross file systems, store files on the same file system as the tools you plan to use, Linux files for Linux command-line work, Windows files for Windows tools such as Notepad [s1c5]. The author is explicit that the doc page gives the recommendation and nothing about the mechanism, and separates vendor documentation from everything that follows [s1c6].

The mechanism, presented as community analysis plus the author's own measurements rather than vendor material, is that reaching `/mnt/c` from WSL2 goes over the 9P protocol [s1c7]. 9P caps how much data a single round trip can carry, the `msize` parameter, and on the Windows-side client that value is currently fixed and not user-changeable, per microsoft/WSL#9125 [s1c8]. Guides telling you to raise it are, the author says, likely describing Linux-side mount options for a different setup [s1c9]. The load-bearing detail is that the cap applies per round trip, not per byte moved overall, so opens, closes and existence checks accumulate cost fast [s1c10]. Multiple GitHub issues, #4197 and #5103, describe the same pattern of small discrete operations taking the worst of it [s1c11]. On the question of whether WSL2 has moved to a newer transport, the author reports that in their environment, at time of writing, it is still the legacy 9P path, and tells readers not to take that on faith either [s1c12].

That is why the benchmark matters more than the diagnosis. Make a directory under `~`, time a loop of 300 `echo x > "f$i"` writes, time the deletions, then repeat under `/mnt/c` [s1c13]. On the author's machine both creation and deletion came out an order of magnitude slower on the Windows side, with creation showing the bigger gap: a fraction of a second on Linux, several seconds on Windows [s1c14]. That is 1,200 timed file operations in total, which is small enough to run before you argue about it [s1c15].

Two cautions from the same post. Run the single-large-file read as well rather than assuming one big operation is automatically cheap, because how the cost lands depends on the specific operation, not only which side of the boundary you are on [s1c16]. And the post also documents a syscall-level check to identify which calls are paying, plus fixes with their side effects stated [s1c17].

What to watch: whether your own environment is still on the legacy path, since the author's answer is environment-specific and dated to their machine [s1c12]; and where your build genuinely needs Windows-side visibility, which is the case the recommendation to keep files with their tools does not resolve for you [s1c5].