Slow file operations in WSL? Check Linux storage and /mnt/c

File listings or dependency tasks can feel slow in WSL even when the same PC handles other work comfortably. Before changing CPU or memory settings, check where your tools run and where the project’s files are stored.

WSL 2 can work with files in the Linux filesystem and files on Windows drives through paths such as /mnt/c. Both are usable, but Microsoft’s guidance is to keep files on the same side as the command-line tools doing the work.

Identify where the tools run

Start with the build or package-management process. A Windows tool launched from PowerShell and a Linux tool launched inside WSL use different environments. A Windows editor window alone does not tell you where its build process runs.

For a project handled by Linux command-line tools, a folder under the Linux user’s home directory, such as /home/yourname/projects, is a useful starting point. Files processed with Windows command-line tools generally belong in a Windows working folder. If both environments need the same files, consider the main workload alongside the need to share them.

Check the current storage location

Open the project’s folder in a WSL Linux terminal and run these read-only commands. They display the current path and information about the filesystem containing that location.

pwd
df -T .

A result beginning with /mnt/c/... normally refers to files on the Windows C drive. Likewise, /mnt/d/... refers to the mounted D drive. These paths take a different route from a directory in the Linux user’s home.

df -T . also shows the filesystem type and mount location. Read those together with the path rather than treating one filesystem name as a universal test. With symbolic links or additional mounts, a directory name that looks like a home directory may not tell the whole story.

Compare a small working copy

If you are considering a different location, try a small working copy without credentials or business data before moving an existing project. Use the same file structure, Linux tool, and operation in each location.

One run can include startup work or benefit from cached data. Repeat the operation and alternate the order so a single timing does not decide the result. Faster file enumeration does not establish that an entire build or a network download will improve by the same proportion.

Workloads that inspect many small files differ from those reading a few large files. Compare an operation close to your actual work. If the location makes little difference, processing load or time spent waiting for network activity may be more useful things to investigate next.

Access Linux files from Windows

Windows File Explorer can also access files stored inside Linux. Microsoft’s instructions describe entering \\wsl$ in the address bar and choosing the distribution. If you have several Ubuntu registrations, select the one where you are working.

Being able to open a file from Windows does not mean that the file is stored on the Windows filesystem. Check the route used by your editor and build tools as well, so your choice of storage remains consistent with how the project is processed.

Consider project placement separately from disk capacity

Putting a project in the Linux filesystem serves a different purpose from moving the WSL distribution itself to another Windows drive. If C-drive capacity is the problem, the distribution’s storage location may need attention too. Before changing an environment you depend on, having a WSL backup that you can restore under another name gives you a way to check recovery.

When a container needs to exchange output files with Windows, a WSL containers bind mount is another relevant workflow. Choose based on whether the task mainly processes files with Linux tools or needs direct sharing with Windows.

References

• Microsoft Learn: working across Windows and Linux file systems
• Microsoft Learn: set up a WSL development environment