{
  "id": 1471653,
  "title": "Why WSL2 Is Slow on /mnt/c, and How to Find the Exact Operation Costing You Time",
  "url": "https://urgent.news/2026/08/17/why-wsl2-is-slow-on-mnt-c-and-how-to-find-the-exact-operation-costing",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-17T11:25:52.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/nomurasan/why-wsl2-is-slow-on-mntc-and-how-to-find-the-exact-operation-costing-you-time-40o7"
  },
  "original_language": "en",
  "account": "The issue of WSL2 being slow when accessing files on the /mnt/c drive is not due to the performance of WSL2 itself. The slowdown occurs because crossing the boundary between the Windows filesystem and the Linux filesystem carries a noticeable overhead. This overhead is particularly impactful when the workload consists of numerous small operations, such as creating or deleting hundreds of small files. In tests, creating 300 small files on the Windows side took significantly longer than doing the same on the Linux side.\n\nMicrosoft's documentation explicitly advises storing files on the same file system as the tools you plan to use. They recommend using the Linux file system for Linux-based tools and the Windows file system for Windows-based tools. The recommendation is clear: to minimize the performance impact, handle large files directly on the appropriate file system rather than dividing the same 1GB of data into thousands of small files across both file systems.\n\nThe problem lies in the protocol used to transfer data between the two file systems, called 9P. The Windows-side client has a fixed limit (currently unchangeable) on how much data a single round trip can carry. This limit applies per round trip, not overall, so operations that generate multiple small round trips—such as opening, closing, and checking the existence of each small file—experience significant slowdown.\n\nTo identify the specific cause of the slowdown in your setup, follow these steps:\n\n1. Time identical operations on both the Linux and Windows sides. For example, create and then delete 300 files, then time both the creation and deletion processes on each side. You should observe that operations on the Windows side are considerably slower.\n\n2. Identify which system calls are causing the delay. Use the `strace` tool to trace the system calls made by your benchmark script. Compare the per-call times for `openat` and `newfstatat` between the Linux and Windows sides. A syscall with a much higher per-call cost on the Windows side indicates where the performance penalty is being incurred.\n\n3. Count how often your script crosses the boundary. Use the `stat` command to determine which side of the filesystem boundary a given directory resides on. Then, run your script and use `strace` with the `-e trace=openat` flag to count how many times it crosses the boundary. A high count suggests that a large portion of the script's execution time is spent crossing the filesystem boundary.\n\nOnce you've identified that the boundary crossing is the issue, consider restructuring your data to minimize the number of small operations. Either store large files directly on the Linux file system or group small files into fewer larger files when working with Windows-based tools. These strategies will help reduce the number of costly boundary crossings and improve overall performance.",
  "summary": "cp crawls. npm install takes forever. The exact same command, run one directory over, is instant. If you've used WSL2 long enough, you may have hit this. This post covers what's actually causing it, and how to find the specific culprit in your own setup — once you know that, the fix is usually obvious. TL;DR: WSL2 itself isn't slow. Crossing the boundary between the Linux filesystem and the…",
  "key_points": [
    "WSL2 slowdown on /mnt/c due to Windows-Linux filesystem boundary crossing",
    "Large number of small file operations cause significant performance impact",
    "Microsoft recommends storing files on appropriate file system to minimize slowdown"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}