WSL 1 had fast IO but couldn't support all features.
WSL 2 supports all features but has famously slow IO.
Example:
1. Shell into WSL
2. Clone a repo
3. Make a bunch of changes to the repo with a program within WSL
4. Run git status (should finish in less than a second)
5. Open repo from a Windows IDE
6. Run git status. This makes windows change each file's permissions, ownership, etc... so it can access the files as git status recursively travels through every file and folder
7. Go for coffee
8. Go for lunch
9. Git status finished after 35 minutes.
10. Close IDE
11. Shell back into WSL
12. Make a change in WSL
13. Run git status from within WSL
14. Wait another 35 minutes as Windows restores each file's ownership and permissions one by one
------------------------------------
The IO overhead is so bad that Microsoft built two new products just to get around it:
1. VSCode WSL remote-client architecture.
VSCode acts as a server within WSL and a client within Windows. Connect both VSCode instances (through proxy/tunnel if needed) and the server can perform the client's File IO ops on behalf of the client rather than letting an Application on Windows try to interact with any of WSL's file systems.
2. Windows DevDrive
Basically set aside a virtual-disk/partition and set it up as a different file system (ReFS) that doesn't use Window's file permissions, ownership and doesn't decrypt then decompress on each file input, doesn't compress then encrypt each file output, and doesn't virus scan the files on usage.
TL;DR Store the files on a network drive and hope race-condition ops from both WSL and Windows don't corrupt any files.
