Comment by chris_money202
13 hours ago
You’re not supposed to work out of the /mnt/c. A lot of people make this mistake and then complain that WSL is slow. On the native linux file system WSL is 100x faster for everything
13 hours ago
You’re not supposed to work out of the /mnt/c. A lot of people make this mistake and then complain that WSL is slow. On the native linux file system WSL is 100x faster for everything
On my work laptop I made the lazy/naive mistake of mounting my projects from macOS into devcontainers running in Colima.
vscode extensions using ripgrep in parallel in the background (there are many!) are killing the vm.
I now decided to follow Mitchell Hashimoto choice and use VMware Fusion and simply do all my work inside of it.
On top of the performance issue you mentioned, /mnt/c will be case-insensitive and trip up lots of Linux software!
That's the entire appeal of WSL (for me). A single source checkout I can work on from both sides; no inconsistency of forgetting that I need to apply changes twice.
Without it, I can just as well ssh into another box.
I've generally found it better to do it other way around - keep all the stuff in Linux partition and from Windows side access that over the virtual network share \\wsl.localhost\<Distro>\home\me\whatever
Trust me, its not worth the performance cost. Just use git push and pull across the /mnt/c boundry
I do this on wsl1 without issue. wsl2 has an experimental new virtual (or just remote?) fs you can enable but I have not tested it.
From the perspective of user empathy, wsl seems to be designed for that use case. but the implementation/defaults can be improved
I do not really follow how you would avoid this if you are using WSL containers with dev containers. Wouldn't this be the default?
>You’re not supposed to work out of the /mnt/c.
Source?
Microsoft now launches a pop-up discourging this, so that is my source. Also my own personal experience using WSL for 8 years.
You can very easily measure this as well, use any disk benchmark