In WSL1, running "wsl git status" on a moderately sized repo on an NTFS (Windows side) drive or SMB file share is nearly instantaneous.
In WSL2, running the same command takes over 30 seconds. WSL2 is a massive hit to the seemless experience between the two operating systems with filesystem performance from Linux to Windows files orders of magnitude worse. Yes, unzipping tarballs or manipulating and stat syscalls are cheaper now on the Linux side. The downside performance loss is, however, staggering for the files I had in C:\
Don't even get me started on how long an npm install took.
One of the truly wonderous things about WSL1 was the ability to do something like this in a PowerShell window:
Now performance across the OS boundary is so bad, I wouldn't even think of using "wsl grep" in my C drive. Or "wsl npm install" or "wsl npm run test" or any of that.
It's very depressing because WSL1 is so, so promising and is so close to feature parity. WSL2 should definitely stick around and has use cases, for Docker it's unparalleled. But for daily driver mixed OS use, WSL2 has made me very unhappy. I think I'll be deconverting my various WSL distributions because the performance hit was too much, it just was absolutely unbearable to even run simple commands in my Windows side.
My understanding was that there were some hard-to-impossible problems to solve to really accelerate the filesystem access from the Linux side under WSL1.
That meant that people doing disk-intensive workloads on the Linux side noticed a big slowdown compared to a native Linux system - certainly e.g. running a big test suite, or a git checkout felt really incredibly slow.
The switch to a VM flipped this relationship round - so now the formerly native / NTFS side is the second-class citizen, but you get the expected performance when putting your files on the "Linux side". For me (doing fs-intensive Rails development), this was a big win.
WSL2 will also quite happily gobble so much memory that Windows slows to a crawl (especially filling Linux's disk buffers on file copies) - that seemed like an odd default, - you just have to pop a .wslconfig in to restrict its usage.
I agree with the other posters here that the WSL1 approach seemed far more elegant, and probably the only way to "not see the joins"- with WSL2 we're worrying about filesystem boundaries _and_ memory now, probably forever. So I hope someone still working that nice seamless syscall layer for a future WSL3.
That was not my experience with WSL1; I was regularly running into unimplemented features. Some examples: the Z3 solver used clock_gettime for timeouts, and their specific usage was broken in WSL1 so you'd get random failures depending on how long the solve took. And don't get me started on running Chromium.
It felt like WSL1 would be running into the long tail of compatibility issues for years.
But I'll admit that I don't try to use it the way you do, I run WSL precisely so I'll never have to launch cmd.exe.
Clearly the best solution is for Microsoft to (a) write a proper ext4 driver for Windows and (b) find some way of embedding SIDs into ext4, then you could just format the drive as ext4, boot off it, and have the improved performance.
(This is mostly a joke, but the performance of NTFS for certain operations has always been abysmal, and having a virus scanner injecting itself into all the operations only makes it worse.)
WSL2 is really not designed for using Linux tools on your NTFS-based filesystem. Store everything on the WSL filesystem, that works perfectly. If you need GUI tools try VcXsrv.
Deactivating Windows Defender for the subsystem‘s storage folder helps somewhat, but I agree that the situation makes the WSL close to broken for many potential users.
I don't blame MS for giving up. Think about how complex it is to maintain a custom version of the Linux kernel which isn't a kernel but a wrapper for your very foreign OS. I'm surprised they even went that route.
My guess is they people who put it together were under the assumption that Linux should be as simple as to implement as the old Windows Subsystem for Unix and POSIX API.
So if accessing ntfs from wsl is now slow, you can put the files in wsl instead. The problem then, if you're using this as a dev machine, is how do you edit them in Windows? I want to use my JetBrains IDEs to edit wsl files, if that doesn't work I'd just stick with dual boot.
WSL1 was a great invention but Microsoft gave up on it, either because of the filesystem performance problems or because of the debuggers. https://github.com/microsoft/WSL/issues/2028 (lldb, rr, delve all affected). This looks like a dreaded case of the first 90% is easy, it's the second 90% that is hard. Imagine implementing a translator for a vast majority of Linux syscalls just to find certain flavors of ptrace are just not doable. I do not have insider knowledge to ascertain this happened but this would be my educated guess.
WSL2 is a VM like any other VM with an uncertain promise for better networking experience and even less certain promise for cross OS file performance which is much, much worse than WSL1 which was already abominable. https://github.com/microsoft/WSL/issues/4197#issuecomment-60...
It was a very nice dream, pity it didn't work out.
Because I am using an eGPU Windows 10 needs to stay as the primary OS on the laptop. I bought a little fanless machine from Aliexpress (with laptop-like hardware) for <$300 USD it'll be my home Linux server. What can one do?
I guess https://www.reddit.com/r/VFIO/comments/am10z3/success_thunde... could be a solution if I wanted to go back to Linux primary but I really badly don't want to. Constant hardware headaches were par for the course -- I was solely Linux 2004-2017. I don't want to be again. If there would be a cheap remote sysadmin service... but it doesn't exist. QuadraNet will sysop a server for $39 a month, that'd be awesome for a laptop... but I have never seen anyone doing that.
> He further mentions that unzipping tarbars could see a 20 times performance increase.
Boy, do I love unzipping tarbars! On a more serious note, it’s great that WSL has gotten much faster, although it’s a little disappointing that they threw out the older, more interesting architecture to get it and just used a VM.
VMWare [0] will also support the Hypervisor Platform Api [1] allowing it to run besides WSL2 which uses Hyper-V. VirtualBox is still struggling and runs slow if at all with WSL2 and Hyper-V [2]
This of course has implications on how you setup Docker on a Windows machine, each way having pros and cons.
This is a worrisome development. We seem to be heading toward a future where hypervisor drivers can only be provided by Microsoft, and you're out of luck if they don't do the job.
Hypervisors that need more capability are going to have to do some crazy stuff to stay compatible. One option is to save and restore the whole hypervisor state whenever it runs. Another option is to be some sort of boot loader, seizing the hypervisor capability before Windows can get to it.
I switched to WSL2 a month ago and it's been great. With WSL1 I'd regularly run into subtle compatibility problems but haven't seen anything like that with 2. Despite a handful of annoyances, the Win10+WSL2+Visual Studio Code Dev environment has been a lot more pleasant than OSX.
Question -- from what I understand, WSL2 is closer to Linux running in a VM, whereas WSL1 was like a Windows kernel level version of Cygwin. Is that mostly correct?
Regarding that, remember a number of years ago, prior to VMs there was a patch set for the Linux kernel porting it to user space -- so you could run Linux as a user process, which ended up functioning similar to running it in a VM. Would WSL2 be closer to this model, or is it really running Linux under a stripped down Hyper V?
> Question -- from what I understand, WSL2 is closer to Linux running in a VM, whereas WSL1 was like a Windows kernel level version of Cygwin. Is that mostly correct?
Yes, that's essentially correct. You could also think of it as WINE in reverse; one big difference from cygwin is that it runs unmodified binaries rather than needing to recompile.
> prior to VMs there was a patch set for the Linux kernel porting it to user space -- so you could run Linux as a user process
Kind of. But from a userland perspective, Cygwin is a (very slow and complicated) layer between the application and the kernel, whereas WSL1 really is (and importantly, feels) like just another API for the exact same kernel. That's kind of its entire advantage over Cygwin, so I wouldn't really compare them like that.
On a Win10 host, I want to edit code in sublime and have the runtime environment in linux. I want fast code search and fast build times.
I've found no way to accomplish the above.
Code in Windows + Windows Sublime means build in WSL will be slow because cross-os i/o
Code in Linux + Windows Sublime means code search will be slow because cross-os i/o
Code in Linux + Linux Sublime + Winodws Xserver means interface is laggy because, well, Xserver
VSCode gets around this by running in a client/server model with client on Windows and Server in Linux... but then I'm stuck with an Electron based editor instead of Sublime.
People commonly say that, but with WSL 1 it was technically quite correct: it’s a Windows Subsystem, for providing Linux. Linux Subsystem for Windows would arguably be slightly inaccurate. The name just feels so strange because Windows hasn’t had many such Subsystems (win32 has essentially been the only one this century).
Under WSL2, the WSL name is no longer technically accurate at all, but it’s what everyone knows it as, and the difference normally doesn’t matter, so they keep it.
I think of it as "Windows Subsystem for [running] Linux".
The architecture descends from the Windows NT architecture:
The user mode layer of Windows NT is made up of the "Environment subsystems", which run applications written for many different types of operating systems, and the "Integral subsystem", which operates system-specific functions on behalf of environment subsystems.
Though as other users pointed out, in WSL 2, the name is inaccurate.
For those of you who will be running Docker Desktop on WSL2 - which allows to "transparently" use the "docker" command on your other Linux that runs in WSL2. And allows to use your WSL2 "other Linux" filesystem to share volumes with Docker containers! ..
Anyway, you need to know that when this stupid Docker and/or WSL2 VM is taking up all your Windows 10 memory - not all is lost.
Using these two commands, you can force WSL2 to give back the memory it is holding prisoner!
echo 1 | sudo tee /proc/sys/vm/drop_caches
echo 1 | sudo tee /proc/sys/vm/compact_memory
Especially if the one doing the mess is the "VM" of Docker.
Now that Docker Desktop is using WSL2 instead of its own VM, you can't see the bastard in Hyper-V console at all... apparently the whole WSL2 VM is not seen in Hyper-V console, even though it IS a damn VM. But it does appear in Task Manager as "Vmmem" and taking up gigabytes of your memory.
I would really, really love to go back to using Linux natively but sadly the hardware on this laptop is not supported well enough. So I eventually gave up and installed Windows while using WSL2 extensively.
Performance is on par with running Linux natively. I compiled my own kernel with ext4 encryption support, and it works quite well. I use it for 90% of my files. Combined with the new Windows Terminal and VSCode support for WSL, there is little friction left. (Also, to address some comments, you can view Windows files from Linux and Linux files from Windows, with some reduced performance.)
Is there a shell+terminal+font combo that folks really like for WSL? I've tried the new terminal beta with zsh and--for reasons I can't quite articulate right now--it feels "off" and I invariably proceed to boot up virtualbox for my debian, i3, kitty, fira code setup to get work done. Maybe it's the break in filesystems and $HOME?
Edit: learning that WSL2 does away with the syscall-translating tech and mandates Hyper-V, the question of whether to look into this further becomes thornier!
A great step. but I feel I have to repeat my "ceterum censeo" of saying that wsl would really benefit, if Microsoft would add a native Wayland support so that the Windows Deskop would appear as a Wayland server for the Linux VM. This would allow any Wayland-compatible Linux application to run seamlessly on the Windows desktop and fully utilizing the native graphics drivers.
I recently wanted to run some linux apps on windows (simple stuff like ls, ssh-keygen, etc) and found that most instructions were actually pointing me to install a ubuntu VM rather than use the native subsystem stuff touted a couple years ago.
I was a little disappointed in this. Running a VM is a lot more hassle than just running the apps natively.
I've been using WSL1 for a long time now and I am very happy with it.
The way I use it is to have all my files and project on windows FS and I code using windows software (VSCode, Eclipse) but when I build and test, I use WSL1, and I didn't feel that the performance was that bad since I have an SSD and I don't mind waiting for few more minutes to rebuild a project.
But the most important thing for me was that I didn't care about managing another file system. All my files are still on windows where I used to keep them, file sync and backups are working as expected, and I easily browse and edit these files on the Windows side.
For docker, I installed docker on Windows and hooked Docker CLI on WSL1 to it using some configurations. and I was happy with it.
The question is, for the way I use WSL1, will WSL2 be an improvement or a drawback for me? and should someone like me switch to WSL2?
[+] [-] AaronFriel|5 years ago|reply
In WSL2, running the same command takes over 30 seconds. WSL2 is a massive hit to the seemless experience between the two operating systems with filesystem performance from Linux to Windows files orders of magnitude worse. Yes, unzipping tarballs or manipulating and stat syscalls are cheaper now on the Linux side. The downside performance loss is, however, staggering for the files I had in C:\
Don't even get me started on how long an npm install took.
One of the truly wonderous things about WSL1 was the ability to do something like this in a PowerShell window:
C:\some-code-dir\> wsl grep -R "something" | Some-PowerShell | ForEach-Item { }
Now performance across the OS boundary is so bad, I wouldn't even think of using "wsl grep" in my C drive. Or "wsl npm install" or "wsl npm run test" or any of that.
It's very depressing because WSL1 is so, so promising and is so close to feature parity. WSL2 should definitely stick around and has use cases, for Docker it's unparalleled. But for daily driver mixed OS use, WSL2 has made me very unhappy. I think I'll be deconverting my various WSL distributions because the performance hit was too much, it just was absolutely unbearable to even run simple commands in my Windows side.
[+] [-] mattbee|5 years ago|reply
That meant that people doing disk-intensive workloads on the Linux side noticed a big slowdown compared to a native Linux system - certainly e.g. running a big test suite, or a git checkout felt really incredibly slow.
The switch to a VM flipped this relationship round - so now the formerly native / NTFS side is the second-class citizen, but you get the expected performance when putting your files on the "Linux side". For me (doing fs-intensive Rails development), this was a big win.
WSL2 will also quite happily gobble so much memory that Windows slows to a crawl (especially filling Linux's disk buffers on file copies) - that seemed like an odd default, - you just have to pop a .wslconfig in to restrict its usage.
I agree with the other posters here that the WSL1 approach seemed far more elegant, and probably the only way to "not see the joins"- with WSL2 we're worrying about filesystem boundaries _and_ memory now, probably forever. So I hope someone still working that nice seamless syscall layer for a future WSL3.
[+] [-] ahupp|5 years ago|reply
That was not my experience with WSL1; I was regularly running into unimplemented features. Some examples: the Z3 solver used clock_gettime for timeouts, and their specific usage was broken in WSL1 so you'd get random failures depending on how long the solve took. And don't get me started on running Chromium.
It felt like WSL1 would be running into the long tail of compatibility issues for years.
But I'll admit that I don't try to use it the way you do, I run WSL precisely so I'll never have to launch cmd.exe.
[+] [-] pjc50|5 years ago|reply
(This is mostly a joke, but the performance of NTFS for certain operations has always been abysmal, and having a virus scanner injecting itself into all the operations only makes it worse.)
[+] [-] dleslie|5 years ago|reply
Shame, it was really good.
[+] [-] sz4kerto|5 years ago|reply
[+] [-] michaelgrafl|5 years ago|reply
[+] [-] ddevault|5 years ago|reply
[+] [-] saurik|5 years ago|reply
[+] [-] the8472|5 years ago|reply
Also, IO performance of WSL1 wasn't exactly great either compared to native linux filesystems.
[+] [-] veesahni|5 years ago|reply
[+] [-] g_langenderfer|5 years ago|reply
[+] [-] MisterTea|5 years ago|reply
My guess is they people who put it together were under the assumption that Linux should be as simple as to implement as the old Windows Subsystem for Unix and POSIX API.
[+] [-] eloff|5 years ago|reply
[+] [-] reiyi|5 years ago|reply
[+] [-] chx|5 years ago|reply
WSL1 was a great invention but Microsoft gave up on it, either because of the filesystem performance problems or because of the debuggers. https://github.com/microsoft/WSL/issues/2028 (lldb, rr, delve all affected). This looks like a dreaded case of the first 90% is easy, it's the second 90% that is hard. Imagine implementing a translator for a vast majority of Linux syscalls just to find certain flavors of ptrace are just not doable. I do not have insider knowledge to ascertain this happened but this would be my educated guess.
WSL2 is a VM like any other VM with an uncertain promise for better networking experience and even less certain promise for cross OS file performance which is much, much worse than WSL1 which was already abominable. https://github.com/microsoft/WSL/issues/4197#issuecomment-60...
It was a very nice dream, pity it didn't work out.
Because I am using an eGPU Windows 10 needs to stay as the primary OS on the laptop. I bought a little fanless machine from Aliexpress (with laptop-like hardware) for <$300 USD it'll be my home Linux server. What can one do?
I guess https://www.reddit.com/r/VFIO/comments/am10z3/success_thunde... could be a solution if I wanted to go back to Linux primary but I really badly don't want to. Constant hardware headaches were par for the course -- I was solely Linux 2004-2017. I don't want to be again. If there would be a cheap remote sysadmin service... but it doesn't exist. QuadraNet will sysop a server for $39 a month, that'd be awesome for a laptop... but I have never seen anyone doing that.
[+] [-] saagarjha|5 years ago|reply
Boy, do I love unzipping tarbars! On a more serious note, it’s great that WSL has gotten much faster, although it’s a little disappointing that they threw out the older, more interesting architecture to get it and just used a VM.
[+] [-] molticrystal|5 years ago|reply
This of course has implications on how you setup Docker on a Windows machine, each way having pros and cons.
[0] https://blogs.vmware.com/workstation/2020/01/vmware-workstat...
[1] https://docs.microsoft.com/en-us/virtualization/api/hypervis...
[2] https://forums.virtualbox.org/viewtopic.php?p=473538
[+] [-] souprock|5 years ago|reply
Hypervisors that need more capability are going to have to do some crazy stuff to stay compatible. One option is to save and restore the whole hypervisor state whenever it runs. Another option is to be some sort of boot loader, seizing the hypervisor capability before Windows can get to it.
That'll be some tough code to debug.
[+] [-] ahupp|5 years ago|reply
[+] [-] derekp7|5 years ago|reply
Regarding that, remember a number of years ago, prior to VMs there was a patch set for the Linux kernel porting it to user space -- so you could run Linux as a user process, which ended up functioning similar to running it in a VM. Would WSL2 be closer to this model, or is it really running Linux under a stripped down Hyper V?
[+] [-] yjftsjthsd-h|5 years ago|reply
Yes, that's essentially correct. You could also think of it as WINE in reverse; one big difference from cygwin is that it runs unmodified binaries rather than needing to recompile.
> prior to VMs there was a patch set for the Linux kernel porting it to user space -- so you could run Linux as a user process
User Mode Linux (UML; https://en.wikipedia.org/wiki/User-mode_Linux), which I think is still a thing, although not super popular.
> Would WSL2 be closer to this model, or is it really running Linux under a stripped down Hyper V?
Not even stripped down; it's running Hyper V. (This is one of the big problems with WSL2; if you use it, you can't use non-HyperV virtualization.)
[+] [-] mehrdadn|5 years ago|reply
Kind of. But from a userland perspective, Cygwin is a (very slow and complicated) layer between the application and the kernel, whereas WSL1 really is (and importantly, feels) like just another API for the exact same kernel. That's kind of its entire advantage over Cygwin, so I wouldn't really compare them like that.
[+] [-] bitwize|5 years ago|reply
[+] [-] veesahni|5 years ago|reply
[+] [-] minxomat|5 years ago|reply
[+] [-] freeone3000|5 years ago|reply
[+] [-] veesahni|5 years ago|reply
I've found no way to accomplish the above.
Code in Windows + Windows Sublime means build in WSL will be slow because cross-os i/o
Code in Linux + Windows Sublime means code search will be slow because cross-os i/o
Code in Linux + Linux Sublime + Winodws Xserver means interface is laggy because, well, Xserver
VSCode gets around this by running in a client/server model with client on Windows and Server in Linux... but then I'm stuck with an Electron based editor instead of Sublime.
[+] [-] rkagerer|5 years ago|reply
[+] [-] chrismorgan|5 years ago|reply
Under WSL2, the WSL name is no longer technically accurate at all, but it’s what everyone knows it as, and the difference normally doesn’t matter, so they keep it.
[+] [-] javagram|5 years ago|reply
https://docs.microsoft.com/en-us/cpp/build/reference/subsyst...
After WSL was dropped in favor of the VM approach in WSL2 it’s just a zombie name though I think?
[+] [-] macca321|5 years ago|reply
>Because we cannot name something leading with a trademark owned by someone else. > >Think of it as Windows' Subsystem for Linux. >#ApostrophiesMatter
Just be glad we didn't call it Subsystem For Running POSIX/GNU/Linux Binaries on Windows (SFRPGLBW)
[+] [-] kbutler|5 years ago|reply
The architecture descends from the Windows NT architecture:
Though as other users pointed out, in WSL 2, the name is inaccurate.[+] [-] aspaceman|5 years ago|reply
[+] [-] kesor|5 years ago|reply
Anyway, you need to know that when this stupid Docker and/or WSL2 VM is taking up all your Windows 10 memory - not all is lost.
Using these two commands, you can force WSL2 to give back the memory it is holding prisoner!
Especially if the one doing the mess is the "VM" of Docker.Now that Docker Desktop is using WSL2 instead of its own VM, you can't see the bastard in Hyper-V console at all... apparently the whole WSL2 VM is not seen in Hyper-V console, even though it IS a damn VM. But it does appear in Task Manager as "Vmmem" and taking up gigabytes of your memory.
[+] [-] brkattk|5 years ago|reply
[+] [-] jdsully|5 years ago|reply
Your essentially getting the "real thing" with pretty seamless integration to the rest of windows. I'd never want to go back to WSL1.
[+] [-] cowmix|5 years ago|reply
[+] [-] TaylorAlexander|5 years ago|reply
[+] [-] saagarjha|5 years ago|reply
[+] [-] evertheylen|5 years ago|reply
Performance is on par with running Linux natively. I compiled my own kernel with ext4 encryption support, and it works quite well. I use it for 90% of my files. Combined with the new Windows Terminal and VSCode support for WSL, there is little friction left. (Also, to address some comments, you can view Windows files from Linux and Linux files from Windows, with some reduced performance.)
[+] [-] sk5t|5 years ago|reply
Edit: learning that WSL2 does away with the syscall-translating tech and mandates Hyper-V, the question of whether to look into this further becomes thornier!
[+] [-] _ph_|5 years ago|reply
[+] [-] MAGZine|5 years ago|reply
I was a little disappointed in this. Running a VM is a lot more hassle than just running the apps natively.
Feels like a step backwards than a step forward.
[+] [-] bithavoc|5 years ago|reply
[+] [-] abol3z|5 years ago|reply
The way I use it is to have all my files and project on windows FS and I code using windows software (VSCode, Eclipse) but when I build and test, I use WSL1, and I didn't feel that the performance was that bad since I have an SSD and I don't mind waiting for few more minutes to rebuild a project.
But the most important thing for me was that I didn't care about managing another file system. All my files are still on windows where I used to keep them, file sync and backups are working as expected, and I easily browse and edit these files on the Windows side.
For docker, I installed docker on Windows and hooked Docker CLI on WSL1 to it using some configurations. and I was happy with it.
The question is, for the way I use WSL1, will WSL2 be an improvement or a drawback for me? and should someone like me switch to WSL2?
[+] [-] lostmsu|5 years ago|reply