>A pathway to a blazingly fast WSL?
>A pathway to a blazingly fast WSL?
I use Haskell for my ever continuing self-education and compiling and linking times with ghc under WSL2 is at least twice as slow as the same operations under native Linux on a much less capable machine.
It is not just me, it is acknowledged WSL2 is very slow in I/O: https://www.phoronix.com/review/windows10-okt-wsl/2
I use WSL2 for reasons but I think I will be much better off with Linux.
I remember no questions being asked when I set up WSL2.
I really doubt that WSL2 will be at native speed with the Linux file system, because reads and writes still have to go through Windows kernel to be mapped into actual hardware reads/writes.
No, Linux is running alongside Windows, not under it. Windows itself is virtualized when WSL2 is turned on, and both Linux and Windows run under Hyper-V. It's quite fancy actually.
Is there documentation/explainer for this? I've been trying to understand more about this (was this a change in Windows 11? Is it only when WSL2 is installed?) for a while now, but not found anything apart from stray HN comments every now and then.
That Windows is then running virtualized is just how Hyper-V works, as soon as you turn on Hyper-V the host Windows runs as a guest in Hyper-V, though with special privileges [1]
https://learn.microsoft.com/en-us/virtualization/hyper-v-on-...
WSL1 is not an NT subsystem, either. WSU (the POSIX subsystem) was an actual NT subsystem, but with WSL, they abandoned this concept and went with a different design for performance reasons.
This is still a problem with WSL2, at least on my WSL2 with Windows file system mappings.
I tried to use instructions that use fossil from the hctree page: https://sqlite.org/hctree/doc/hctree/doc/hctree/index.html
Fossil employs sqlite to store SCM information and it fails with "SQLITE_IOERR(1290): os_unix.c:39533: (22) fsync(...)" error, which is the same with VirtualBox: https://www.fossil-scm.org/forum/forumpost/7fb6c96d80?t=c
So WSL2, having to put up with Windows quirks, is not much a Linux anymore. It is slow and some programs can't even run.
But if WSL2 is given its own drive to mount and do what it wants with it, the issue should disappear.
And when WSL2 supports passing partitions, the issue will vanish.
https://en.m.wikipedia.org/wiki/Hypervisor#Classification
https://learn.microsoft.com/en-us/windows-server/administrat...
If the (WSL) path to your project is inside ~/ it's on the linux file system. If it's in /mnt/c/ it's in the Windows filesystem. In WSL1 those were about equally fast, both going throught the windows kernel. With WSL2, accessing /mnt/c/ from Linux has to go through Windows, and accessing \\wsl$ from Windows has to go through Linux, so where you put the files decides where they are fast.
Yes, WSL1 was great. I hope it will never be sunset, as I need good IO performance.
> where you put the files decides where they are fast.
I also also hope we'll eventually get an option to pass partitions to HyperV, which is currently possible only with full disks.
It would be a return to the previous WSL1 level of performance for files within a NTFS partition: even if you'd need a separate NTFS partition, that'd be a minor nuisance to guarantee performance.
I had the same doubts, but when I finally took the time to install it, I found out that I was wrong. One Java program that I use, which is very heavy on the filesystem and slow like hell under Windows it a LOT faster under WSL2.
As Java profiler support is poor on Windows, I now use WSL2 to run async-profiler sessions and get results as accurate as on native Linux.
EDIT to add: you really have to run things fully in the WSL2 filesystem, be it for compiling or using a program. The performance is awful if you run WSL2 processes under the Windows filesystem.
NTFS is awful at doing lots of small accesses on very small files, at least compared to Ext4. Add to that the fact that if you're on WSL, it needs to write POSIX attributes (which NTFS has no support for and therefore WSL must emulate), and that's a recipe for builds being slowed massively by IO.
As for Defender, well, Defender sees new files and halts everything while it scans them. You can see how that can be a problem for a process that pops out tens of thousands of temporary files, which it will all go and scan, locking them while it does so.
With ntfs3 (kernel 6) this is no longer true, as can be seen for example in Arch install living next to windows on C:\ https://gist.github.com/motorailgun/cc2c573f253d0893f429a165...
Also NTFS has had POSIX attributes support - they just weren't used before.
WSL1 doesn't support POSIX attributes, just like ntfs-3g didn't support them, but it's not a limitation of NTFS.
What do you find that VirtualBox does better than Hyper-V?
If you need good IO performance, WSL1 is still a valid option.
I need good IO performance, and it's not clear how much of the overhead is due to NTFS, and how much is due to 9p (to pass the VHDX file on the NTFS partition to WSL2)
So I'm planning some experiments with OpenZFS for windows and NTFS3 (https://old.reddit.com/r/zfs/comments/10lcnpk/zfs_raw_passth...), first using a WSL2 kernel with the option enabled (https://github.com/microsoft/WSL/issues/8564 and https://github.com/bioluks/WSL2-Linux-Kernel-NTFS) then WSL1.
I have a dual NVMe setup and W11 for Workstations, so it should be possible to run a passthrough of both partitions to the kernel.
However, it's not clear yet how to do that with a VHD on VHDX: most of the documentation I've read about VHD (or VHDX) refers to a passthrough as an "old" option: https://www.altaro.com/hyper-v/hyper-v-pass-through-disks/
As the computer has 2x NVMe and 2x GPU, it should be easy to do a GPU passthrough (with one GPU for Linux native, the other in passthough to Windows) but this brings a little extra complexity I'd rather avoid if I can.
> They are both impacted by storage overhead
If you're accessing files through SMB or something then sure, it'll be slow.