Accessing the Windows filesystem from WSL and vice versa is extremely slow, so running for example your IDE in WSL and having your code etc. stored in WSL is useful. I think that is one of the big usecases. It's already kinda supported in vscode, where it runs a vscode server in WSL and Windows just runs the frontend.
It's useful for me when developing dotnet intended for Linux as I can store the code in WSL and be able to build, debug, run docker and so on directly from vscode.
Why is it so slow? I use VMware player and swapping files is fine. WSL2 seems like it's just using a lightweight VM over HyperV... is Hyper V really that much worse than VMware (and VBox) in this?
WSL2 uses 9P (of the venerable Plan 9 pedigree, I assume because Erick Smith is a nerd!) to remote the filesystems. I don't think that's part of HyperV (though it could be a custom VSP/VSC, and that channel is ridiculously slow.)
Personally I haven't run into slowness other than Windows sucking at copying lots of small files, which is NT's fault for allowing FS filter drivers and their ridiculous locking scheme.
Accessing the WSL filesystem from WSL is indeed a lot faster on WSL2. Accessing the Windows filesystem from WSL or vise versa is even slower in WSL2 compared to WSL1.
> As you can tell from the comparison table above, the WSL 2 architecture outperforms WSL 1 in several ways, with the exception of performance across OS file systems.
WSL2 disk access from the Windows side is very slow. It's the reciprocal problem of WSL1.
WSL2 Linux apps now get proper performance now but if your IDE is on the Windows side, access time to project files on native Linux partition is terrible.
...actually e.g. VS Code has a really great split backend, so you can actually have the frontend "properly" on Windows anyway, and yet still use WSL2.
My own case was something different: annoyingly configured automated browser tests with Cypress. Just running them inside WSL and letting that start a browser on the distro itself was the most comfortable way to debug these.
But I mean come on, they're Microsoft. If they really wanted filesystem access to be efficient across systems, we'd have it by now. Although convenient, I doubt that's on their list of primary motivations for doing this.
Seeing how every file system (NTFS) imrovement since windows 7 (like new compression methods) is done in layers running on top of ntfs. I think that Microsoft has either lost the source to ntfs driver or institutional knowledge of how it works.
It's useful for me when developing dotnet intended for Linux as I can store the code in WSL and be able to build, debug, run docker and so on directly from vscode.