[wsl2] filesystem performance is much slower than wsl1 in /mnt
ioweb-gr opened this issue · comments
I decided to open this as a separate issue because although it's related to the generic issue of filesystem performance it's directly related to WSL 2 while the other issues are for WSL 1 and it's showing very conflicting results.
-
Your Windows build number: (Type
verat a Windows Command Prompt)
Version 10.0.18917 Build 18917 -
What you're doing and what's happening:
I'm testing filesystem write speed in /mnt using dd command. Performing the following tests
WSL2
root@LUCIANO-PC:/home/# dd if=/dev/zero of=/mnt/e/testfile bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 25.939 s, 40.4 MB/s
WSL1
root@LUCIANO-PC:/home/# dd if=/dev/zero of=/mnt/e/testfile bs=1M count=20000
20000+0 records in
20000+0 records out
20971520000 bytes (21 GB, 20 GiB) copied, 47.4897 s, 442 MB/s
On / it's actually the reverse. WSL2 is more than 2 times faster than WSL1.
- What's wrong / what should be happening instead:
I would expect the filesystem performance in /mnt to at least be on the same level but it's over 10 times slower.
Another interesting fact is that if I mount the same drive as a cifs share I get 3x performance
WSL 2 (cifs share)
root@LUCIANO-PC:/mnt/sambae# dd if=/dev/zero of=/mnt/sambae/testfile bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB, 9.8 GiB) copied, 84.001 s, 125 MB/s
An update of the current status because it's way too hidden in this thread.
Latest status report: #4197 (comment)_
On / it's actually the reverse. WSL2 is more than 2 times faster than WSL1.
Can you post the results when doing the same test on a file on / for WSL1 and WSL2?
This is straight I/O on a single file where I would expect to see more or less the same perf between WSL1 and WSL2. My expectation was that WSL2 perf is better than WSL1 only when doing "namespace" operations (i.e. working on lots of small files, listing them, stat'ing them, etc.)
As for the results on /mnt/e they are not very surprising, since I/O has to go through both the Linux and Windows file system stack in likely a new and unoptimized piece of code.
I see,
I'm assuming you're still refering to / and not /mnt folders about namespace operations.
I've repeated the write tests in both environments a few times now and there's no consistent result.
WSL 2
root@LUCIANO-PC:/home/# dd if=/dev/zero of=/testfile bs=1M count=10000/testfile bs=1M count=20000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB, 9.8 GiB) copied, 7.0873 s, 1.5 GB/s
root@LUCIANO-PC:/home/# dd if=/dev/zero of=
20000+0 records in
20000+0 records out
20971520000 bytes (21 GB, 20 GiB) copied, 51.3779 s, 408 MB/s
root@LUCIANO-PC:/home/#
root@LUCIANO-PC:/home/# dd if=/dev/zero of=~/testfile bs=1M count=20000
^C12360+0 records in
12360+0 records out
12960399360 bytes (13 GB, 12 GiB) copied, 12.1766 s, 1.1 GB/s
WSL1
root@LUCIANO-PC:/home/# dd if=/dev/zero of=~/testfile bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB, 9.8 GiB) copied, 29.7096 s, 353 MB/s
root@LUCIANO-PC:/home/#
I'm thinking this has to do something with OS Caching because in task manager even though I can see the file being written, the disk usage write speed is unchanged while in wsl1 I can see it constantly at around 350mb/sec .
As another interesting fact, the vmmem usage while writing the file is increasing rapidly. By the 3rd copy action all my RAM is used up (32GB).
It goes back down a while after quitting my shell. So maybe the performance is bottlenecked by this bug as well.
I'm also experiencing this after an upgrade to WSL2, only slow performance under /mnt, not /, slower than WSL1. I can post numbers as well if necessary. This is on Microsoft Windows [Version 10.0.18936.1000].
I'm experiencing the same issue, /mnt is extremely slow compared to WSL1 (seconds to run git status on a relatively small repository).
When I run a git status on a clone of https://github.com/hashicorp/terraform in /mnt I get output like this:
It took 6.97 seconds to enumerate untracked files. 'status -uno'
may speed it up, but you have to be careful not to forget to add
new files yourself (see 'git help status').
This is an example from the command
pv files.tar.gz | tar -zxf -
The speed is amazingly slow in wsl2 on /mnt
Do we know what's at the root of this, and whether there are any other workarounds than downgrading?
@definelicht - Yep we're working on improving the performance. In the meaning working out of your root file system (the ext4 volume) will have MUCH better performance.
Indeed after the last update I can already see much better performance on WSL2.
root@LUCIANO-PC:~# dd if=/dev/zero of=/mnt/e/testfile bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB, 9.8 GiB) copied, 41.277 s, 254 MB/s
That's on an SSD and it's like 6 times faster than before. Still slower then WSL1 but it's definitely improved.
--correction---
I see much better performance on sequential writes. Untar seems very slow still extracting data at bytes/sec while in wsl1 I can see speeds at kb/sec for the same part
Indeed after the last update I can already see much better performance on WSL2.
root@LUCIANO-PC:~# dd if=/dev/zero of=/mnt/e/testfile bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB, 9.8 GiB) copied, 41.277 s, 254 MB/sThat's on an SSD and it's like 6 times faster than before. Still slower then WSL1 but it's definitely improved.
--correction---
I see much better performance on sequential writes. Untar seems very slow still extracting data at bytes/sec while in wsl1 I can see speeds at kb/sec for the same part
I got
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 3.57894 s, 293 MB/s
but git status still taking more than 2 seconds on quite small repo
I think this is a latency rather than a bandwidth issue, surfacing when a large number of files are accessed (e.g., when running git status).
@definelicht - Yep we're working on improving the performance. In the meaning working out of your root file system (the ext4 volume) will have MUCH better performance.
can you share the cause of it? I'm curious
can confirm a very bad performance on /mnt (mvn install takes forever), on /tmp it takes only 2 minutes for the same project
After switch configuration from WSL to WSL 2 (Build 18975), without any change on my distro, the server respond time incresed.
Configuration : Debian buster Apache2.X / PHP-FPM 7.3 / MySQL
Root : /
Web directories : /c/repositories/xxx
WSL 1 : 0.5 sec
WSL 2 : 8 sec
With Docker (Ubuntu 18.04) WSL Tech preview i could not test on WSL 1, but WSL 2 takes over 30 sec... I suppose the issue is the same.
This is my performance in a medium project:
GIT_TRACE_PERFORMANCE=1 git status -sb -uno
13:20:04.630972 read-cache.c:2267 performance: 0.017249300 s: read cache .git/index
13:20:07.766270 preload-index.c:146 performance: 3.135180100 s: preload index
Refresh index: 100% (3463/3463), done.
13:20:53.531359 read-cache.c:1575 performance: 48.900269600 s: refresh index
13:20:53.981829 read-cache.c:2267 performance: 0.016242500 s: read cache /mnt/e/p/keyed_au/.git/ modules/Files/media/nusoap/index
13:20:54.383135 read-cache.c:1575 performance: 0.401222700 s: refresh index
13:20:54.426399 diff-lib.c:251 performance: 0.000005000 s: diff-files
13:20:54.468000 unpack-trees.c:1554 performance: 0.000087700 s: traverse_trees
13:20:54.468266 unpack-trees.c:465 performance: 0.000164900 s: check_updates
13:20:54.468346 unpack-trees.c:1649 performance: 0.000438000 s: unpack_trees
13:20:54.468368 diff-lib.c:537 performance: 0.001873400 s: diff-index
13:20:54.569793 read-cache.c:2989 performance: 0.014679900 s: write index, changed mask = 2
13:20:54.586550 trace.c:477 performance: 0.736638600 s: git command: /usr/lib/git-core/git status --porcelai n=2 -uno
13:20:55.277184 read-cache.c:2267 performance: 0.031572000 s: read cache /mnt/e/p/keyed_au/.git/ modules/Files/modules/unittest/index
13:20:55.958706 read-cache.c:1575 performance: 0.681302500 s: refresh index
13:20:56.007094 diff-lib.c:251 performance: 0.000003500 s: diff-files
13:20:56.041768 unpack-trees.c:1554 performance: 0.000081200 s: traverse_trees
13:20:56.042014 unpack-trees.c:465 performance: 0.000162100 s: check_updates
13:20:56.042084 unpack-trees.c:1649 performance: 0.000399800 s: unpack_trees 13:20:56.042102 diff-lib.c:537 performance: 0.000454400 s: diff-index 13:20:56.126615 read-cache.c:2989 performance: 0.012095500 s: write index, changed mask = 2 13:20:56.141174 trace.c:477 performance: 1.261971900 s: git command: /usr/lib/git-core/git status --porcelain=2 -uno 13:20:56.148677 diff-lib.c:251 performance: 2.586112000 s: diff-files 13:20:56.190888 unpack-trees.c:1554 performance: 0.000022200 s: traverse_trees 13:20:56.191028 unpack-trees.c:465 performance: 0.000027800 s: check_updates 13:20:56.191106 unpack-trees.c:1649 performance: 0.000639200 s: unpack_trees 13:20:56.191175 diff-lib.c:537 performance: 0.001413100 s: diff-index
13:20:56.215068 trace.c:477 performance: 51.628126000 s: git command: git status -sb -uno
File System exFat, the result is the same is other file system...
WSL 2 git=51.62 sec
git for windows=0.8 sec
I'm currently using the normal Docker Desktop with linux containers to run a PHP projekt during local development. The repo is in a normal Windows directory and gets mounted via volume bind in the docker container, so that I can easily manipulate the files through an IDE.
The same setup on a native linux machine has always been multiple times faster and the "problem" (from what I've read) has always been attributed to the Linux VM that is used on Docker Desktop.
Then WSL 2 was announced and I finally came around to set everything up. But when I ran our teststuite for the first time, I was pretty disappointed that the performance was actually much worse than before (40s on the Docker Deskop Linux VM setup vs 100s on the WSL2 setup). Subsequent investigation brought me to this thread.
From what I've read here so far:
Does it even make sense to switch to WSL 2 for local development yet if "bad performance" is your primary reason to do so?
A "no" would be a totally acceptable answer - I just don't want to waste any more time on this if it's simply not ready yet.
I know that wsl2 is a preview, but is there any hope that accessing \wsl$ from windows or /mnt from wsl will reach acceptable speeds?
I'd also like to ask about this, doing a git status on something in /mnt/c/.. takes about a minute, something seems wrong ..
same with 1903 (18990.1) absolutely useless...
I am also seeing this, accessing Windows files from the Linux environment is several orders of magnitude slower in WSL2 than in WSL1.
Same for me on build 18985
Still happening @ build 18990
This experience is being worked on, thank you for posting updates on the build numbers that you are still seeing this issue, but please keep in mind that this can make a fair amount of unnecessary noise for users who are subscribed to this thread, so I'd ask if you could please not do so.
When there are changes in this area, i.e: things that will affect file performance in the mounted drives, we (the WSL team) will be sure to post updates in this thread. Thanks!
A possible workaround for slow git could be to use git.exe from WSL2. For me a git status with linux git takes 15 seconds while using git.exe takes 0.3 seconds.
A possible workaround for slow git could be to use git.exe from WSL2. For me a git status with linux git takes 15 seconds while using
git.exetakes 0.3 seconds.
Can confirm this behaviour:
You should see how long npm and composer take to install dependencies :) we can't really alias all commands to the windows counterparts so although it's a workaround I'm hoping we'll see a real solution soon. Currently we are forced back to building things on our linux machines
A possible workaround for slow git could be to use git.exe from WSL2. For me a git status with linux git takes 15 seconds while using
git.exetakes 0.3 seconds.Can confirm this behaviour:
I've been using a little wrapper script like:
#!/bin/bash
# WSL 'git' wrapper, save as /usr/local/bin/git and chmod a+x
REALPATH=`readlink -f ${PWD}`
ARG1=$1
MORE_COMMANDS=(log diff)
if [ "${REALPATH:0:5}" == "/mnt/" ]; then
# echo "Using windows git.exe"
if [[ " ${MORE_COMMANDS[@]} " =~ " ${ARG1} " ]]; then
git.exe "$@" | more
else
git.exe "$@"
fi
else
# echo "Using linux /usr/bin/git"
/usr/bin/git "$@"
fi
Same issue on Windows 10 18995
Poor performance of file access to /mnt compared to /
Git is 10x slower
Cusom prompts using Git are unusable
I know this goes without saying, but accessing files outside of WSL is absolutely unusable at present. I'm going to have to revert back to WSL1 until this is fixed.
Just adding my experience to the list of already well documented experiences.
Filesystem access on /mnt/d is unusably slow.
Accessing files in ~ is fine, however
In build 18999 the performance is actually decreased compared to previous builds. For all purposes it's completely unusable. Even tab completion is much slower than before taking over 10 seconds to list the files on an SSD.
@ioweb-gr - I looked through the commits in that build and nothing jumps out at me that would explain a massive slowdown. Do you have more data you can share?
Of course, what would you need from me in order to help?
I first noticed it while trying to commit a change to a single file which 20 seconds later hadn't been completed. With windows git it took less than a second for the same operation.
@ioweb-gr - Is the issue still present?
let me convert the machine back to wsl2 and get back to you. Since it was taking way too long I reverted it to wsl 1.
Actually I tried it with another instance which is version 2 and yes the issue persists. While trying tab-completion in the same folder in /mnt it's very slow.
So I'm trying git add compo then pressing tab and waiting to autofil ser.json and it's taking way too long compared to previous version.
ll compo then tab autocompletes it instantly though.
@ioweb-gr I did some research into this, and it appears that this slowdown is caused by the bash-completion script used by git. For git add, this script tried to find all modified files in the repository, for which it needs to "stat" every file, which can be somewhat slow (equivalent to git status).
However, I found this was only really slow if the repository was cloned by Git for Windows. In this case, it seems there's a mismatch between the attributes git expects and the results it gets from stat, so git ends up rehashing every file in your repository. This is not the case if the repository was cloned using git on WSL.
Did you clone your repository using Git for Windows?
Hey @SvenGroot, I cloned a small repo inside WSL 2 and it takes nearly a minute to do a git status. Other programs are similarly painful if accessing files outside of WSL's environment. Doing a git status on the same repo inside WSL 2 takes about a tenth of a second.
Had to revert back to WSL 1. The issue seems to be global for me.
Hi @SvenGroot there is high chance it was cloned using git bash for windows since cloning repositories over wsl2 takes ages usually. I'll try in the next days and experiment with different cloning methods and see if the issue persists when it's cloned via wsl.
Please note that for WSL2, we recommend that you put your files in the Linux file system (not under /mnt) whenever possible. It will be much faster (than WSL1 even) and you can still work on them from Windows using \wsl$ or tools such as Visual Studio Code Remote.
We realize that accessing Windows files in WSL2 is slow. We're working on ways to make this better, but not all of those will be ready for the 20h1 release.
the issue also crosses the boundary when accessing \wsl$ in windows. For instance, I cloned a repo in wsl 2 and am attempting to work on it from sublime. The access is so slow that sublime can't actually index the directory and any plugin also suffers from terrible performance.
Is the 20h1 release the official public release? If fixes for this won't be in for this release, when can we expect them? WSL 2 will be DOA until then for me
@SvenGroot I understand what you mean however for us it's not always possible to do it like this unfortunately. It very much depends on your workflow for that matter. If I put everything on / I would have to move everything of my projects on my main OS disk which is bad and unsafe. I currently keep them on a separate mirrored drive comprising of 3x2TB SSDs which is mounted on /mnt under wsl but is also portable if needed.
I guess for a lot of people having small ssds on OS there is gonna be a similar workflow so the need to use fast files on /mnt becomes much more important as time passes
If you use the wsl --export and wsl --import commands, it's possible to move your Linux files to a location other than the system drive. This works for both WSL1 and WSL2.
But trust me, we know Windows file system interop performance is important, and we spend a lot of resources trying to improve it.
Yes I understand that, for my personal reasons I can't export the environment out of my OS drive becauce of automated deployments running here, so unfortunately I cant use that solution. I'm glad your working towards this and I know it's not easy effort. My only concern is that instead of seeing improvement in WSL2 I saw a huge leap backwards when it comes to access /mnt areas so somewhere down the road I think the importance of having this perform as well as possible was overlooked.
In the process I sacrificed VMWare in order to have WSL2 running on Hyper-V because of better compatibility with different functions (for example I couldn't perform git commits in /mnt before in WSL1 as the builds progressed) so I'm just considering this:
If I used vmware for a linux environment with mapped network folders I could achieve the same thing WSL2 does for me with better speeds. Comparing the benefits of each solution makes it very hard to choose WSL2 at the moment over WSL1.
I tested on WSL1 and WSL2. The result is
WSL1
$ dd if=/dev/zero of=~/testfile bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 0.351729 s, 3.0 GB/s
WSL2
$ dd if=/dev/zero of=~/testfile bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 1.18549 s, 885 MB/s
I've recently been having "I/O" exception issues when trying to do a "git status" in WSL2 - and needing to reboot to restart the VM - I suspect it has to do with running both windows git and linux git at the same time on the same repository. I wish I could create a simple way to repro it - but it's happened at least twice in the last two days. Does anyone know if there is a way to "reboot" WSL2 without a full computer restart?
Lol, the new wsl2 is just a VM with network-mounted /mnt folders. So it is expected result to being such slow. I don't know why this WSL2 project exists at all, but it's better to use just Hyper-v or other VM, where i can mount windows folders with SMB or smlz, just like you did it.
On the other hand, wsl1 is VM-free solution, and that's why it's cool and low-latency. You better to improve WSL-kernel to be able to use docker and other heavy soft in wsl-1, without VM-overhead
Pls fix this issue. I can't use WSL2 because the /mnt is too slow... A simple "git status" will kill it in a bigger project....
👍 to get this fixed. Running in /mnt performance has ground to a halt, and I am having to revert back to WSL 1 to continue working
it is really slow, not only for git but for everything that's watching files, my dev server that is watching files takes forever to restart. i'ts adding 30s plus for every restart/reload, this is kinda deal-breaker for me after investing time to try it instead linux as my dev machine where the restart almost instant.
I'm not sure whether this was worth kicking out vmware for wsl. I'm pretty sure I could map stuff through samba and have faster file access. I've been going through release notes and I do not see a single release that was focused on improving performance in /mnt.
Plus I've been using windows tools more often now to unzip, untar, commit etc etc than when WSL started
I will be use WSL1 until WSL2 solve this problem.
Just try out the WSL 2 today on Build 19013.vb_release.191025-1609 and notice the performance drop on /mnt/. I have to continue to work in a VM until this is fixed, because there are no way to work with PHPStorm/WebStorm without accessing files in mounted drives.
Fyi. With every passing version it's getting worse instead of improving. I can't even run composer anymore because it times out checking out git repositories. Reverted to WSL1 today on my main instance
Any roadmap on fixing this issue?
Folder /mnt/c is too slow.
Rarely rollbacking has been so satisfiying.
How is this even released...
I've started noticing recently that disk activity on /mnt/d (SSD on C:, HDD on D:) is reaching 100% easily sometimes, even when there's nothing intentionally using anything on that disc or any folder/file inside it (see edit below) I couldn't trace what exactly is triggering this activity or being accessed there, but I can say that almost nothing has changed on my use pattern or on the linux image to justify this, other than constant fast-ring updates. It does feel, through my anedoctal evidence, that IO is not getting much better with time.
Let me know if there's any way I can monitor in details such a scenario involving WSL2 so that I can provide more information and maybe help identify bottlenecks.
I'm really hoping WSL2 will improve on IO the same way it has improved recently on memory usage (it's amazing now).
EDIT: I was so into the *nix mindset that I had forgotten I have access to the amazing Resource Monitor from Windows, which now shows that the thing getting constantly bombarded is pagefyle.sys, though not only by vmmem. I can say now that this issue on my case is not really immediately IO then, but overall resource consumption (that is only augmented by a suboptimal IO environment).
The thing is, I have RAM available for everything to fit in there, but a lot of disk activity still routes to windows virtual memory...
just use docker inside linux vm ;)
Also i don'k understand, why there is no ways to get access to windows drives without network just with forwarding read&writes to nt kernel...
seems like the project is developing by early-courses students
Still experiencing this in December... wsl2 is pretty much unusable if you need to work out of any thing not already in the linux file system.
Just +1
I did some measurements using the latest slow ring WSL2 as of today and wrote them up in this blog post: https://vxlabs.com/2019/12/06/wsl2-io-measurements/
WSL 2 is currently about 5x slower than WSL 1 accessing files on NTFS.
However, WSL 2 is showing such great potential everywhere else, so I really hope that MS is able to address this issue also!
The same here - starting a node project (using AdonisJS framework) takes about 30s on WSL2 while around 5s on WSL1. I have to go back until this is solved..
Is.this impossible to fix?
Yeah, somehow the newest insider build got even slower.
So far I've converted all my machines to WSL1 again until this gets better. Please do let us know when there are updates regarding this so we can retest for you.
I just wanted to +1 this as well
+1
My primary use case is running phpstorm in the Windows GUI and Linux command line tools on the same set of files. I do not look forward to switch to phpstorm on Linux as support is (obviously) lesser and one of the reasons I didn't even try native Linux on the current laptop is hotplugging GPUs all the time (TB3 eGPU) and so I really do not wish to touch X unless there's some X Server which doesn't go hardware level but then how's performance? Anyways, I hope this gets resolved. It seems we got from the frying pan into fire.
Agreed @chx , This file access performance issues is just killer and making the wsl2 not usable, sticking to wsl1 for now
Please cut it with those “me too” comments. The issue is there, well-documented, acknowledged, probably being addressed. There's absolutely no need to constantly remind all 44 subscribers that there's still nothing new here.
The issue affects you, we get it. Just add a reaction to the initial comment, subscribe, and do NOT comment unless you have anything useful to add to what's already been said.
Moigagoo: thank you for fighting for all of the subscribers that can't handle the notification spam, but other people lending their support to an issue to attempt to get a major problem fixed is not a problem for everyone. Open-source github issues users generally follow the accepted "+1/me too" pattern, but for those who are inconvenienced by the notifications, you can just instead bookmark this page and unsubscribe to the notifications. I am not looking to start an internet fight or trolling competition, but personally I appreciate the "+1"s here and on many issues I track, so I am defending those following this path. stop notifications
I am also affected by the issue referenced here and hope that this has enough traction that it is being working on actively. Look forward to testing the fix when its available.
i kinda don't mind the notifications, and somehow was hoping for some sort of the official comment. for me i jumped back to linux and invested more time there. i just cannot work with this performance and i got tired of all the workarounds. im suprised that they would release this kind of quality even for beta.
I think that some regular status updates (if there are any) on the progress of this issue from people who are overseeing this project would probably stop people spamming
Hi everyone, thank you for the discussion here on /mnt performance in WSL2. We realize this is a dealbreaker for many of you commenting here, and we are looking into ways to improve this, and make the file system performance faster in /mnt drives.
As of right now, if you can move your project over to the Linux file system, please consider doing so and using a WSL2 distro running Linux applications accessing files in your Linux file system for faster file performance. If your use case requires you to access Windows files, please feel free to move back to a WSL1 distro, or consider having a WSL1 distro and a WSL2 distro side by side for your different applications.
We'll be sure to post any updates on this thread as soon as they are available. Thank you for your patience!
@craigloewen-msft I'm new here, could you please clarify, what do you mean by "move your project over to the Linux file system"? Should I format a part of my disk in linux format and somehow tell wsl to use it? ah, now I see that the problem is in mnt, sorry
Yes, this is a dealbreaker. I was very excited to hear about WSL2 and the performance improvement just to find that it actually is much slower. My use case is using and IDE from windows on code that also want to run/test in linux.
@archfz most IDE's should be able to connect remotely to the WSL2 IP address. Have you tried that? I'm using VScode and the VScode remote plugin and it works well, and it is much faster than WSL1 on windows filesystem, especially with docker applications.
As I understand jetbrains support is not yet ready.
@archfz JetBrains IDEs complain that it is a network drive and file watching may be limited/not work.
A workaround for this is to create a NFS Server on Windows 10 and mount it on WSL 2.
I have some Wordpress apps running on docker and it was very slow to load anything. After I have created the NFS server on Windows 10, mounted it on (in my case) /var/nfs and started my containers from this folder, my applications got running really faster.
A workaround for this is to create a NFS Server on Windows 10 and mount it on WSL 2.
Hi @lucasctd, what nfs server did you use? Did you find a built in method or is it a third party application? Thanks!
@andrewleech I am using Allegro NFS Server. Unfortunately it's not free, im using its trial version. I will look for a free one later xD.
Just fix the issues with WSL1, please.
I use it from the very beginning and switched from OSX to Windows because of this.
Using a VM for development is a horrible pain in many-many ways, that's why people left you for a mac in the first place including me.
Big Chinese giants started selling laptops with Linux on them and the competition is growing with a speed we have never experienced.
Only a proper Windows - Linux integration can keep up with a working Linux desktop.
This is a major threat to your business and you have no control over it apart from WSL1. In a few years, half of the world will not be able to run their software on windows if you stick with VMs.
Windows Vista was a pile of flowers and you haven't given up, you can do it with WSL1 too.
+1
Incredible. I'm on 19035, doing basic package installs.
$ composer install
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Package operations: 120 installs, 0 updates, 0 removals
- Installing google/apiclient-services (v0.65): Loading from cache
It's been sitting like that for 10 minutes running unzip under the hood.
How big is that zip you ask?
7.5 Megabytes
It's a lot of small text files.
WSL was released with some serious hype. I've spent the time to get all our developers using it just so we can get some cheaper windows laptops but at this point I'm spending more time trying to support this configuration than it would cost to simply get Macbooks for everyone.
If you release WSL2 like this my recommendation will be to drop Windows entirely.
@hparadiz I've since downgraded from WSL2 -> WSL1 until the performance issues are resolved. The main limitation of this is that I cannot run docker naively, so I have docker desktop for windows running. WSL1 is amazingly fast for my use cases, which include heavy usage of docker, java and python.
Really looking forward to being able to migrate my workflow to WSL2, though, as I'm sure we all are.
EDIT: Or, you can of course, not work in a /mnt/ drive, which should resolve your performance issues, albeit with other downsides.
@andreialecu I did it - inside WSL2 linux partion everything IS fast & smooth. However - I am using Windows based PHPSTORM IDE, which cannot access those files. I can map a network drive (\wsl$\ubuntu\home...) but then it is slow again.
Is it possible to get some indication of whether we are looking at weeks or months for a resolution?
We are also in the 'Docker + WSL2' boat and can get by for a while if there's a fix on the horizon, but if not we're better served by holding off on running Docker natively as we can't move our development environments into the linux filesystem completely.
The other devs on my team want to use Sourcetree as a GUI for Git and since they are running it as a Windows app the code must be on a windows drive. Putting the code into the Linux partition is not a solution.
WSL is super cool! I am so excited to try WSL2 (but I will wait for GA 😄)! The comments on filesystem performance in Linux (not /mnt) are very promising!
just move your files to ~ (under the linux partition) and it will be almost as fast as native linux.
Also this tweet: https://twitter.com/benhillis/status/1212819586539646976
2020 is going to be a huge year for Window Subsystem for Linux with the GA of #WSL2 and some incredible unannounced new features.
Can't wait to know more about the unannounced new features. Maybe Microsoft Build 2020? 🤔
I miss easier and better WSL integration from Visual Studio 2019 and Jetbrain IDEs (Rider).
I am OK with having my code in Linux if I can open projects (sln, csproj) with Visual Studio 2019 or Jetbrains Rider. Is that possible? Other comments and issues are telling me that it's not possible right now.
I would love to install nodejs and git only in Linux and use on all my projects. I have web projects that runs on classic .Net Framework and .Net core. Would be great to open them with Visual Studio 2019 but use git, webpack, npm and other nodejs tools (for front-end parts in a .Net project) with WSL and have nodejs to run "almost as fast as native linux".
I am OK with having my code in Linux if I can open projects (sln, csproj) with Visual Studio 2019 or Jetbrains Rider. Is that possible? Other comments and issues are telling me that it's not possible right now.
you can map wsl distros as network drive in windows and then open project in ide (Intellij and other JetBrains ids from 2019.3 even can see $wsl paths without mapping as network drive)
performance in ide is acceptable for my projects
I can confirm the issue.
OS Build 19041.84
WSL2 with Ubuntu-18.04 LTS
Docker under the WSL2 (without Docker Desktop)
docker-compose has next services:
- php-fpm
- nginx
- postgresql
- adminer
Pure Symfony 5 project. docker-compose up -d
from /mnt/c/users/****/symfony Welcome page loading around 2.8 seconds
from ~/symfony Welcome page loading around 50 ms
What I can say, I thought that local development using Windows 10 is real, but current problem with the mnt performance and issue with systemctl (docker cannot run automatically on wsl2 start), make it pointless.
With hope in the best wsl future, Bogdan.
I can confirm the issue.
OS Build 19041.84
WSL2 with Ubuntu-18.04 LTS
Docker under the WSL2 (without Docker Desktop)docker-compose has next services:
- php-fpm
- nginx
- postgresql
- adminer
Pure Symfony 5 project. docker-compose up -d
from /mnt/c/users/****/symfony Welcome page loading around 2.8 seconds
from ~/symfony Welcome page loading around 50 msWhat I can say, I thought that local development using Windows 10 is real, but current problem with the mnt performance and issue with systemctl (docker cannot run automatically on wsl2 start), make it pointless.
With hope in the best wsl future, Bogdan.
There is a project help you to enable systemd in WSL2. wsl2-hacks
A workaround for this is to create a NFS Server on Windows 10 and mount it on WSL 2.
I have some Wordpress apps running on docker and it was very slow to load anything. After I have created the NFS server on Windows 10, mounted it on (in my case)/var/nfsand started my containers from this folder, my applications got running really faster.
hi @lucasctd can you please tell little more about how you did this? Like install that NFS server, configure it to export some directory and then in wsl 'sudo mount %windowsIP%:/someexport ...'? Maybe it need more advanced preconfiguration or firewall tweaks?
Not the perfect, but the working solution for the Intellij idea/PHPStorm/WebStorm. You need to have:
- File Watchers plugin
- startup script
- sync script
On every autosave, the file watcher will run the sync script, which is using rsync to sync the files between mnt and linux partition. The only one problem, this sync process can take around 4-7 seconds, but the project is working fast.
I can share my example with the comment on the important moments, so, you can modify it for your own purpose. HOWEVER, I hope WSL2 team will fix this problem!
start.sh
#!/bin/bash
sudo service docker start
#important, copy the whole project to the linux folder, to speed up initial start of rsync
cp -a /mnt/c/Users/bogh/projects/symfony/ /var/www/symfony/ --progress --no-perms --no-owner --no-group --cvs-exclude
chmod -R 777 /var/www/symfony/var/log/
chmod -R 777 /var/www/symfony/public/
#shellcheck disable=SC2164
cd /var/www/symfony/
docker-compose up
sync.bat
#important, exclude can be different for you as the name of the folders
bash -c "rsync -rvWS /mnt/c/Users/bogh/projects/symfony/ /var/www/symfony/ --no-perms --no-owner --no-compress --exclude .idea/ --exclude .git/ --exclude .docker/ --exclude /var/cache/"
File watchers (select a folder only with the source code, to speed up the file watchers)
@bog-h what is benefits of such complex solution?
i now using next setup:
- project placed inside wsl2
- php run in native linux docker inside wsl (even dont use docker for windows) – speed is basically 1:1 to native linux
- $wsl mounted to network drive W:\
- PhpStrom pointed to folder in network drive – complaining about network drive, slow indexing, but after indexing works fast enough
so i basically choose slower IDE, but faster webserver execution for PHP
but since Jetbrains is not going to make normal wsl support in nearest year, and vscode will remain just fancy text editor forever, and even if WSL team will improve /mnt/c read speeds somehow – it will be anyway not so fast as native
for Microsoft problem is solved by VSCode extension, for Jetbrains problem doesnt exists – too small percent of users involved