[wsl2] filesystem performance is much slower than wsl1 in /mnt

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 ver at 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: https://github.com/microsoft/WSL/issues/4197#issuecomment-604592340_

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/gabtzi# 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, 7.0873 s, 1.5 GB/s
root@LUCIANO-PC:/home/# dd if=/dev/zero of=~/testfile bs=1M count=20000
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 (two orders of magnitude at least).

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.

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

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)

Same as @gbatalski
mvn install on a given project takes over 4 minutes under /mnt/d/... and only 23 seconds under /tmp

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 take over 30 sec... I suppose the issue is the same.

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 imply 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.exe takes 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.exe takes 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.

@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?

@ioweb-gr - Is the issue still present?

let me convert the machin 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.

Hey @SvenGroot, I cloned a small repo inside WSL 2 and it nearly a minute to do a git status. Other programs are similarly painful if accessing files outside of WSL's environment.

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.

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 test 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...  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.  Reverted to WSL1 today on my main instance

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.

what works ok'ish for me is that i access the linux filesystem via network share, map the share to Z: drive and use it like that in IDE. that fileaccess is sometimes slow but is better then nothing.

Any roadmap on fixing this issue?

Folder /mnt/c is too slow.

Rarely rollbacking has been so satisfiying.
How if 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. 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).

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...

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 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 issues to attempt to get a major problem fixed is not a problem for everyone. Open-source github issues users generally always 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. [https://help.github.com/en/github/receiving-notifications-about-activity-on-github/subscribing-to-and-unsubscribing-from-notifications](stop notifications)
I am also affected by the issues referenced here and hope that is 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.

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

They really need to implement some kind of paravirtualized filesystem into the linux kernel, which looks like the didn't do.
VmWare shared folders also have the same performance problems.
Perhaps a better way would just be using iSCSI through localhost. Windows has native support for connecting to it.
I would try it.

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!

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 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.

@hparadiz @nmiodice just move your files to ~ (under the linux partition) and it will be almost as fast as native linux.

@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 had a hope for the local development using Windows 10, 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 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.

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/nfs and 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?

@lucasctd @itspers I've setup FreeNAS on my windows box but am not able to connect to it in WSL - tried a few different IP's. Can you share your setup/progress?

Not a perfect, but a working solution for intellij idea/PHPStorm/WebStorm. You need to have
File Watchers plugin
startup script
sync script
On every autosave file watcher will run sync script which is using rsync to sync files between mnt and linux partition. The only one problem, sync can take around 4-7 seconds, but project is working fast. I can share my example with comment on the critical 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
#that is what you need, copy whole project to linux folder for the beginning
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
#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 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

@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.

I did the testing on my  WSL2. It shows that it's still pretty slow. Any special settings?
$ sudo dd if=/dev/zero of=/mnt/nfs/test bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 19.0654 s, 56.3 MB/s
On my home folder, speed can up to 2GB/s.

I've measured the same program (16k unit tests) in some scenarios as I was looking for a new setup:
WSL 1 in /mnt
real    16m37.403s
user    17m24.031s
sys     62m46.406s
WSL 2 in /mnt
real    17m26.257s << it took like 30 seconds before the first line was even printed.
user    20m4.096s
sys     16m7.990s
WSL 2 in ~
real    3m59.666s
user    15m35.286s
sys     6m25.831s

I've reinstalled my wsl system due to an accident with Kaspersky and let me report my newer tests in build 10.0.19041.84
WSL 2
root@LUCIANO-PC:/mnt/t# dd if=/dev/zero of=/mnt/e/testfile bs=1M count=5000
5000+0 records in
5000+0 records out
5242880000 bytes (5.2 GB, 4.9 GiB) copied, 33.4946 s, 157 MB/s
WSL 1
root@LUCIANO-PC:/mnt/e# dd if=/dev/zero of=/mnt/e/testfile bs=1M count=5000
5000+0 records in
5000+0 records out
5242880000 bytes (5.2 GB, 4.9 GiB) copied, 12.9155 s, 406 MB/s
There seems to be a small improvement from the 40mb/sec that I was reaching when I started this issue but is still less than half the speed of wsl 1

@ioweb-gr
can you added the same stat for wsl OUT of /mnt ?
as it would be an objective comparison of all flow here
especially checking previous comments dropping for "17min" to "4min" look like a 4x diff
as machine spec can't really be compared i guess i can't say wsl would be 1600MB/s => 1.6GB/s
that would be helpfull
even if it mean removing the NFS server to get a real grip on all the various possibilities and respective speed.

The problem with this batch size is that a lot of OS cashing is hitting and I can't get realistic values from ~/
e.g.
on WSL 2
root@LUCIANO-PC:~# dd if=/dev/zero of=~/testfile bs=1M count=5000
5000+0 records in
5000+0 records out
5242880000 bytes (5.2 GB, 4.9 GiB) copied, 4.5053 s, 1.2 GB/s
This outperforms my SSD's speed on C:\ which is a samsung 850 evo drive and a max write speed at around ~500mb/s.
WSL1 shows
root@LUCIANO-PC:/mnt/c/Users/gabtz#  dd if=/dev/zero of=~/testfile bs=1M count=5000
5000+0 records in
5000+0 records out
5242880000 bytes (5.2 GB, 4.9 GiB) copied, 13.7369 s, 382 MB/s
If you want to really compare the performance between the two areas I'd probably need a more realistic sample. Maybe a single block of something that exceeds my RAM capacity which is 32GB.

And based on that I stumbled on another edge case which probably needs looking into. Maybe a new issue since it's happening in ~/
WSL 1
root@LUCIANO-PC:~# sync && echo 1 > /proc/sys/vm/drop_caches
-bash: /proc/sys/vm/drop_caches: Operation not permitted
root@LUCIANO-PC:~# dd if=/dev/zero of=dummyfile bs=1024M count=32
32+0 records in
32+0 records out
34359738368 bytes (34 GB, 32 GiB) copied, 127.69 s, 269 MB/s
root@LUCIANO-PC:~#

WSL 2
root@LUCIANO-PC:~# sync && echo 1 > /proc/sys/vm/drop_caches
root@LUCIANO-PC:~# dd if=/dev/zero of=dummyfile bs=1024M count=32
^C23+0 records in
23+0 records out
24696061952 bytes (25 GB, 23 GiB) copied, 395.398 s, 62.5 MB/s

Let me point here that I had to stop the test because it was taking sooooooo long and my windows was completely unresponsive. Like mouse would move around every 5 seconds or so the file stopped at around 25GB instead of 32GB. At the pace it was going I think it would take a lot longer as it was constantly slowing down more and more.
I dread the thought of doing this in /mnt because I'd have to leave the PC running overnight to finish :D

I had high expectations for WSL 2 until I found this thread. Lots of people recommending mapping a network driver for Jetbrains. If I have to do that, why would I replace my VM for WSL 2? I might as well just keep it.
Today I use a headless VirtualBox with an Alpine Linux that has only Docker and Git installed. Very slim and fast boot. The annoying part is precisely the fact that Jetbrains has to reindex the entire project constantly and changes made inside (git pull) can take several seconds up to a couple of minutes to kick in outside.
I'm very fond of Alpine and I think WSL 2 can only win against such a setup if it can deal with the slowness of sharing files between Windows and Linux.
In fact, I have several coworkers using Macbook and suffering with Docker volume speed as well. This could be huge for Microsoft if the speed could provide developers with the experience of using Windows without sacrificing terminal performance or IDE performance.

no issue if you don't use windows partition in a mount or attempt network bounce.
both have overhead so it's kinda logic
VsCode seems ok with a language server
so you basically have a tooling issue that could be fixed on JetBrain side ?

VSCode and the language server on decent size code bases can make an entire machine unusable (especially if its not being used on an ssd) when running through wsl2 so no its not a tooling issue other than using wsl2 as one of your tools. This definitely needs to be fixed otherwise it's not usable in most cases.

I just tried wsl2 with rely high hopes to die up my development.
I was crushed after trying.
I developing laravel with Docker via workstation VM.
Normal page loads are from 1,5s to 2.0 with Docker bind on the vm.
With wsl2 page loads are about 15(!!!) seconds!
Putting everything out of /mint speeds it up to 90ms... but this is the same speed if I use a regular vm. So why use wsl?

I am wondering if this solution syncing from mnt to linux https://github.com/microsoft/WSL/issues/4197#issuecomment-589257274 could be made faster. It seems to me that the 4 seconds mentioned there can be reduced much more with the right tooling.

I am wondering if this solution syncing from mnt to linux #4197 (comment) could be made faster. It seems to me that the 4 seconds mentioned there can be reduced much more with the right tooling.

Solution 2:

Run Wsl2

cd ~

ssh-keygen -t rsa -b 4096 -C<EMAIL_ADDRESS>

Enter file in which to save the key: MyKey

Enter

Enter

cat MyKey.pub

copy key

cd .ssh

nano authorized_keys

paste key

sudo service ssh restart

cat MyKey

copy key

Goto C:\Users\Me\.ssh

notepad Wsl.ppk

paste key

Create new project c:\var\www\MyProject

Open project in PhpStorm

File > Settings

Exclude Paths: node_modules, vendors, .idea, ...

Menu > Tools > Development > Automatic upload

Goto Wsl2 /srv/http

mkdir MyProject

cd MyProject

make symlink from /mnt/c/var/www/MyProject/.git to /srv/http/MyProject/.git

restore data: git checkout .

npm install

composer...

Now, PhpStorm will automatically upload all changes quickly.
Or you can do it yourself:

Menu > Tools > Development > Upload to...

Solution 2:

Hell of a lot work, if running many different services, but could have a really good performance impact.
BUT after running composer or npm (in die container) we need to sync changes back to the host, so the ide is uptodate.
Running composer directly on the host is no option (why use docker than at all?)
My current solution is the following:

Build my api on a shared folder (via vmwaretools or /mnt (if using wsl))
when the api is ready I build the production image and use that directly in docker and build the Frontend.

Another way would be to put /vendor on a volume and sync that manually if you update composer.

True, as pointed out the syncing is not quite an optimal solution for all projects, for most development cycles you'd need bidirectional syncing which is problematic, so that solution drops for me.
I have tried to run the same development flow from both /mnt in wsl1 and ~/projects wsl2 with a react webpack hot reloaded project and here are my results (SSD + i7-4720HQ + 16gb ddr3):

Bash, npm and git generally perform much better in the second case.
Webpack initial compilation was the same on both: 30s.
Webpack hot reloading was just a little bit slower in first case: 9s in wsl1 vs 6s in wsl2.
Could connect PHPSTORM through the \wsl2 path to the project in wsl2 under /home but the syncing was quite slow, had to wait around 5-10 seconds until files changed from linux side reflected in the IDE.

For this difference it is not worth the change at this point, especially since I also use cypress which I did not manage to run from linux side with xServer on wsl2 (wsl1 works). It also caused other problems as well since the wsl2 uses a little bit different networking mechanism to connect localhost.
I am going to install a dedicated Ubuntu on the same machine and will post results from there as well for performance on the same project.

Back with results for dedicated ubuntu: webpack initial compilation 15s, hot reload compilation 2-3s.

Just my 2 cents to the discussion. I am using devcontainers in vscode alot. I just installed WSL 2 and  activated the docker support for WSL 2 with much hope of even better experience. The WSL 2 makes the devconainers basically useless. Same code (node based docs) is blazingly fast directly under WSL ~/ as described here but very slow in the devcontainer. For me the use-case not be able to use devcontainers in WSL 2 is a dealbreaker. I see two things to work out that issue, improve perf on windows filesystem files and make vscode remoting support using remote docker instances. Then I would be able to run docker in the WSL 2 context instead.
Thanks WSL team for trying to make improvements in this area!

FYI, for anyone put data in ~/, please remember to backup your data first. The version 2004(19041.153 in my case) requires a kernel update and I cannot access my wsl before the update.
https://docs.microsoft.com/en-us/windows/wsl/wsl2-kernel

Just throwing this out there... might be nice to get an X-Server option close to a click and it's ready for a windows X-server (or Wayland) so that one could just run the GUI app (assuming it's cross platform) in the Linux environment.
For that matter, have been considering xming to experiment with, mainly around dockerized apps, unsure if anyone has good tutorials for that.
Would like to see this improve, especially if CIFS mounts are better performing than the default /mnt/X interface.

+1

I've got a gigantic repo (50GB not including builds) for a multi-platform project. I'd like to build from linux using the same source so I don't have to take up double the space on disk. Part of the build process is globbing the source and it just hangs forever.

I am on 19041, I am feeling the same. I run ng new and thinking it's slow because of first time but I can see when I am doing ng serve, it's slowly moving percent to percent in WSL2. Any help on this.

Same here, with git status taking over 1 minute.

I started using WSL2 when migrating from OS X, to get the same terminal experience as I was accustomed to, and since I'm comfortable in Linux. Since I also collaborate with people that works on OS X, most tooling is shell-based, which is also nice.
After a few months trying to run this setup (WSL2, and Docker within WSL2), I have given up completely because it just doesn't work. Problems that arised for me was:
Having my git repo on the windows file system, made certain git calls grind to a halt. git status could take 10-30 seconds to complete for a fairly small git repo. If you have a git prompt script, it would basically do a git status after every command, making it unusable. Moving the git repo into the WSL2 filesystem removes this problem, but editing the \wsl$ drive is not only discouraged, but editing files on the WSL2 drive seems to drive Windows Defender completely nuts. It constantly scans something on the drive (I'm assuming there is a vhdx somewhere but I haven't been able to find it), and it probably scans a full drive for every little file change.
Either way, I switched to WSL1, and git is actually usable from the windows drive. I lose the ability to run Docker in WSL2, but I can use the docker tooling from WSL1 and remotely connect to Docker for Windows which seems like a decent compromise.

Might not be useful for all cases, but it did help in mine.
The issue started for me when I upgraded an existing WSL, by using the command wsl --set-version Ubuntu-18.04 2 followed by wsl --set-default-version 2. At that point WSL started working super slow, specially noticeable when using git commands.
I restarted my laptop after a while, and then bash started crashing at launch with error message "Server execution failed", which prevented me from using bash at all, and forced me to find some workarounds.
Well, It seems like the workarounds to fix the crash helped with performance. The universe works in mysterious ways, right?.
Hence, I wanted to share my findings with you, in case is useful for anyone. Steps I followed:

Open "Turn Windows Features On/Off"

Disable Windows Subsystem for Linux (when it if reboot now, select Don't reboot).

Perform a hard restart (Shift pressed whilst clicking on "Restart").

When it restarts, you'll see recovery options, select "Continue to Windows".

Open "Turn Windows Features On/Off"

Enable Windows Subsystem for Linux back.

Perform a hard restart (Shift pressed whilst clicking on "Restart").

Note: Data from your WSL instance will NOT be affected.

This problem still exists. The issue for me started when I upgrade existing WSL to WSL2. Can't even start vscode with intellisense.

VsCode and Intellisense works perfectly in v2
This is totally unrelated to this issue
Your issue here is more How VsCode works, where is the language server, and where you should install your extensions
==> Extensions need to be installed "on the side" of the Language Server (which runs next to your code => in wsl2)
==> you need to install the C# extensions AFTER VsCode is open
simple repro :

Nope. create-react-app with typescript can't even finish its type checking.

As i have said, I can't even start a development server. Type checking takes too long.

Sorry, i did not understood that, it seems to have been running in less that 10 sec.
I won't do the offense of saying "Works on my machine" as you setup seems to have an issue as you are observing
All i did was creating a project, avoiding /mnt because you should not even try to use /mnt if all you need is create-react-app (just split your repo ?)
I think typecheck / language server / vscode took less than 10sec to startup and being live here.
Sorry for your trouble, i can't repro the issue you are having :(

Either way, I switched to WSL1, and git is actually usable from the windows drive. I lose the ability to run Docker in WSL2, but I can use the docker tooling from WSL1 and remotely connect to Docker for Windows which seems like a decent compromise.

@jishi Just an FYI you can run WSL2 and WSL1 side by side, using WSL2 for the docker for windows runtime and WSL1 for you actual development environment.  Not sure how it will actually affect the performance issues you were having.
`PS C:\Users\dpanzella> wsl --list -v
NAME                   STATE           VERSION

Ubuntu-18.04           Running         1
docker-desktop         Running         2
docker-desktop-data    Running         2`

As the title says .... "if you are in /mnt"
If it's just a create-react-app, just don't work there :)
That fodler exists only if you have a VERY STRONG requirement over sharing in absolutly real time the FileSystem
you could just git clone your project in 2 place if only a very small part need that "sync back"
git remote add wsl ~/src/project
git remote add mnt /mnt/src/project

and you just sync them, that's a way => 0 perf issue
The only scenario shown earlier that could be an issue so far is when their is a strong need to keep a "Windows IDE" not supporting language server

Okay. I'll try to move my projects from /mnt.

In order to keep my sanity when running git commands I decided to keep a Powershell window open and them from there.

This thread is awesome:)
My scenario - PHP/Javascript (Vue.js) project running in Docker. PHPStorm as IDE, using XDebug. Composer on PHP side, Node/NPM on Javascript side. Project is average size, so enough composer/npm packages needs to be installed.

Everything set up on Linux machine - works great & fast. (git, docker, composer, npm, xdebug)

WSL2 seems like very promising concept because I still prefer Windows as Desktop OS for non-development reasons. Also Docker needs to run inside WSL2 (Because Docker in Windows have some strange behavior when running npm packages because of underlying filesystem access issues, which I don't want to debug).
Only way currently is to locate project files under /home/ folder, because /mnt is definetly not working. And PhpStorm IDE access to mounted network folder \wsl$\Debian\home...
Such setup is reasonably doable without too many hacks.
Docker itself (image bulding, etc) works fine. Rest of the stack - not so good. Composer - slower; npm - slower; git - slower; phpstorm indexing - slower; xdebug - slower; nginx - slower; I haven't measured exact timing but it is there.

So - can somebody from @Microsoft finally comment - IF performance is fixable and will be fixed in the future? Thanks:) Version/build: 2004 / 19041.153

So - can somebody from @microsoft finally comment - IF performance is fixable and will be fixed in the future? Thanks:) Version/build: 2004 / 19041.153

That would have been possible at some point before people keep spamming here instead of waiting :
https://github.com/microsoft/WSL/issues/4197#issuecomment-568923487

True and sorry for adding to this spam. Meanwhile - most commented Issues tends to get more attention from the repo owner; some obscure commenter might offer temporary solution (for example, adding Defender exclusions helps a bit); and lastly - it has been more then 8 months since the beginning of this conversation.

So after moving my project directory from /mnt/c... to /home/<user>/... everything became normal again. Just wondering why performance is really really slow on /mnt

So far no reason has been given as to why we took such a performance hit from switching to the overmarketed wsl2 as drvfs users.
Sadly I'm now at a point where it's faster to switch between versions depending on what task I need done.
If I need to compile a new php or ruby I go to wsl2 as it's hours versus minutes. If I want to use git on ntfs drive in /mnt I switch to wsl1 as wsl1 is 20 times faster. If I need to use git on a Refs drive in /mnt back to wsl2 because wsl1 is not compatible.
Webpack is slow, symfony is slow, ruby is slow. We see nothing coming up for a looooong time now.
The wsl devs are aware of the issue but I'm certain by now that it's still in the backlog and not something they would prioritize as the bulk of users are happy to keep everything in the isolated main disk area. I'm not really sure if this thread should still be open as no one can really contribute and there are no updates targetting this almost a year later.
Posting our findings and feedback here as originally intended is only helpful if there is active development for this.
So ultimately the one question that remains for me is whether there are going to be any improvements this year or should I just give up and go back to dual booting? A simple non-vague one-line response would be very helpful

https://docs.microsoft.com/en-us/windows/wsl/wsl2-ux-changes

Yes ok I've already read this article and I understand what you mean but I'm not taking it to extremes here. I want to untar a 75mb tar.gz file and it takes 35 minutes in /mnt on an ssd compared to 2 on wsl1 and less than 30 secs on linux/windows. I can live with 2 but 35? When vmware can do it faster and it's third party? The article mentions in initial builds, but this feels like forever so that's why most people just give up.
It feels the same as it was when asking for windows explorer to support >255 char paths since 2000 all over again (which is still not possible 20 years later) and getting the answer "we've heard you",  if you know what I mean.

In WSL1, file performance was slow compared to Linux because it had to emulate Linux behavior on top of the Windows IO subsystem, which has a very different design than Linux and is slow for many operations that are extremely fast in Linux and therefore used a lot by Linux tools. This was the case for both the "internal" Linux file system, and the Windows file systems mounted in /mnt, because they both use regular NTFS files.
With WSL2, the Linux file system is now an ext4 partition in a VHD. It cuts Windows out of the loop except for having to read/write from/to the VHD file, so that's much, much faster.
Windows files are now accessed across the VM boundary, however. In WSL1, we could just call the NT kernel from our lxcore.sys kernel driver, and that was that. In WSL2, every operation has to send data to the host, exit the VM, wait for the host to perform the operation (which still involves emulating Linux behavior and the cost of Windows IO operations), send data back to the VM, trigger an interrupt in the VM, schedule the virtual processor to run, and continue executing in the VM.
Essentially, Windows files are now a "remote" file system. To access them, we use the 9p file system protocol, a protocol also used by QEMU to provide host file access, and the same protocol we already used to provide Linux file access through \\wsl$. Communication is done over Hyper-V sockets, which is faster than a real network, but it still has many of the same drawbacks as a network file system.
To make matter worse, to ensure the same behavior as WSL1, we don't use any caching. Typically network file system like NFS or SMB will cache both file data and attributes for some amount of time to avoid too many round trips to the server. We are in the unique position where the host and the guest are tightly integrated through things like interop. It's entirely possible that you have a script which runs a git command in WSL followed immediately by some Windows tool. In that case, any cache inconsistency between the host and the VM could cause incorrect behavior, or worse, data loss. Even the 1 second attribute cache used by NFS could be problematic for this reason.
Caching is also problematic because the Linux 9p client only has two real caching modes: none and loose (there's also mmap, which enables caching only for read-write memory mapped files, and fscache, which is irrelevant in this discussion). WSL2 actually uses mmap (because using the "none" option makes certain mmap operations fail entirely). If we wanted to use caching, the only option is "loose", which means Linux will cache data and attributes essentially forever (until the kernel evicts them due to memory pressure), and will never try to refresh from the host, which is obviously not desirable.
Without caching, it means every "stat" operation has to make a round-trip to the host (multiple, actually, partially because of how Linux VFS works, and partially because of how 9p works). It also means that reading/writing files is done using direct IO, which means that the buffer size used by the application is what's used when talking to the host. An application that's using 32KB buffers to read a file will therefore be significantly faster than one that's using 4KB buffers, because it has to do fewer round trips. This will be true for increased buffer sizes up to the maximum message size for 9p, which is slightly under 64KB.
You can actually enable caching by adding the "cache=loose" option to your mount options in /etc/wsl.conf (note: if you do this and convert back to WSL1, DrvFs will fail to mount because it doesn't recognize that option, so you'll have to remove it again). But if you do this, then all bets are off. There is no consistency whatsoever. It's only safe to do this for drives that you only access from Linux (and if that's the case, you should really just move your files to the Linux file system). Also note that because the Linux 9p client does not intelligently implement cache read-ahead, reading files will always use the page size for each round-trip, which is 4KB on most kernels. So reading a file that's not yet in the cache can actually be slower if the application was using a large buffer size, though once the file is in the cache, reading it again will be extremely fast of course.
So, that gives you an idea of why this is slow. This isn't unique to us; cross-VM file access always tends to be slow, and a lot of solutions employ caching to hide that, which is fine because most VMs can't just run executables on the host operating on the same files the way WSL2 can with interop. Unfortunately, we don't have that luxury.
We are constantly working to improve this. We already have an improvement in the pipeline that will reduce the round-trip cost significantly. Unfortunately, despite our best efforts, that improvement was not ready for the upcoming 2004 release of Windows. We are also looking at alternatives to 9p and other improvements we could make to get us closer to at least WSL1 DrvFs performance. And that work is going on in parallel with ongoing efforts to make IO performance in Windows better in general, which we would also benefit from of course.
Is this work going as fast as we, or you, would want? No, unfortunately not. These are hard problems and they take time to solve. We really wanted to have a better story for the initial release of WSL2, but unfortunately, reality just didn't allow it.
So yes, for now the most important thing is: if it's at all possible, store your projects in the Linux file system in WSL2. This will be much faster than anything in WSL1, and gives you the full benefit of WSL2.
We understand that there are cases where you can't do that. All I can tell you is that we know about it, we're not happy with where we are either, and we're working on it as fast as we can. We ask you to be understanding, and know that we will be working on it regardless of whether you keep posting in this thread or not. :)

@SvenGroot Thank you very much for taking the time to provide a detailed report on the current status so we can plan on our side.

Agreed, thanks very much for the detailed update, I'll keep checking this thread.

Let me post my last check for speeds using yarn install

It seems in a simple install task we're actually getting very similar results to other types of connections to the project folder using drvfs on wsl 2.
Based on the detailed explanation let me ask one more thing please.
I'm understanding that maintaining interop in the sense of executing commands from each respective environment on the other and vice versa plays a huge factor in making this extremely difficult to achieve performance for because cache can't be utilized.
I imagine a lot of users may have similar workflow as I have and only use their IDE on windows to access their files, write their code, maybe upload and do other GUI taks and perform some CLI tasks using wsl as a terminal for things that only linux can do without actually having the need to run both type of operations from a single environment / terminal.
Would it be possible to improve performance by enabling caching in this scenario, or would it break stuff even with this type of access?
Speaking for my use case, I have interop set to false in wsl.conf because it caused more issues than it solved, so theoretically would it be safe to turn on caching?

@ioweb-gr Unfortunately, 9p does not offer any caching options that would suit you. While we allow you to turn it on, as I said the only caching option is "loose" which means Linux never refreshes the files once cached. This means that any changes made in your Windows IDE would not be visible to Linux until you either explicitly drop the caches or shutdown WSL (or the vm runs out of memory and needs to evict stuff from the cache).
For your scenario, a 1 second NFS-style attribute cache or an opened files only read-ahead cache would probably work, yeah, but unfortunately 9p doesn't have the ability to do that.
You can of course set up an SMB share with the host using its default caching options, which will likely be faster, but that's not exactly convenient to do, defeating a lot of what makes WSL2 superior to a regular VM in the first place in our opinion, so we definitely want to be able to do better than that in the long term.

Looking forward to a permanent solution for this although, it seems like this is going to take some time so for now, running the GUI app (e.g. PhpStorm in my case) inside WSL2 with X-Server is a better workaround for me.

Looking forward to a permanent solution for this although, it seems like this is going to take some time so for now, running the GUI app (e.g. PhpStorm in my case) inside WSL2 with X-Server is a better workaround for me.

Hi Pal! Do you have a link for a guide? I would like to try to do the same.

@bog-h I'm using X410 and so this article was enough to get me started. From what I've seen in all X-Server apps, the key thing is the DISPLAY variable and getting your X-Server app excluded from your firewall (I only use Windows Defender). At least, this was the case for me.
Then, there's the memory/RAM issue in WSL2 (#4166) and the workaround that worked for me can be seen in my comment on that issue.
This setup seems to work fine for me so far - performance-wise, at least I don't notice any slow downs on my workflow. Unlike when I had the project files under /mnt/<drive>, which I just can't work as the slowness is very noticeable as it is not that astronomically slow in WSL1.

@SvenGroot

With WSL2, the Linux file system is now an ext4 partition in a VHD. It cuts Windows out of the loop except for having to read/write from/to the VHD file, so that's much, much faster.

I have a question if you could answer please.
Would it be possible to create additional VHDs in different drives and mount them as ext4 partitions in the WSL instance? Would they behave as the "linux file system" does in WSL2 performance-wise?
And to take it a step further, would it be possible to mount a whole physical ext4 disk like this?
The reason I'm asking this is because I'm redeploying a main machine with all tools installed every few weeks to multiple systems so I prefer to have all WSL instances on my main drive. However I would like to use a separate place for project files that will still reside in the "linux file system" but on a different physical disk location on the machine or an entirely different physical disk.
I'm assuming if it would be possible it would also cut windows out of the loop and provide full speed similar to how the current main VHD works.

Guys, I think the only solution for this problem is re build a new Windows 11 based on Unix like mac does.

@ioweb-gr They already implemented something very similar. Since build 19018 there is a new folder /mnt/wsl that is shared with every running WSL2 distro. You only need to install a new WSL2 distro in the external disk and then the VHDx will be created there.
After that you can bind mount a folder or mount the sdx device and it will appear in every other WSL2 distro under /mnt/wsl.
For example I have Ubuntu 20.04 on C: and I can access the files in my Alpine distro in partition G:. On the Alpine distro in the user folder I created a .profile with the content

if [ ! -d /mnt/wsl/WORK ]; then
mkdir /mnt/wsl/WORK
mount --bind /home/ /mnt/wsl/WORK/
fi

Now the only thing I need is launching the Alpine distro once so its vhdx is loaded on the main kernel as device /dev/sdc. The /home folder from Alpine will appear in the Ubuntu distro under /mnt/wsl/WORK mounted as ext4 so it will still be fast.

I see the new feature arrived "File Explorer Integration in the Windows Subsystem for Linux (WSL)". Anyone have tried to work with the project via this integration using VSCode or Jetbrains's Ide? Looks promising.
https://blogs.windows.com/windowsexperience/2020/04/08/announcing-windows-10-insider-preview-build-19603/

@bog-h this seems only a shortcut  to the old \wsl$ that is reading linux fs from windows.
Off topic here where the issue is reading the windows partition from Linux ;)

@DanieleCS So am I. I think backend logic might be same.

Guys, I think the only solution for this problem is re build a new Windows 11 based on Unix like mac does.

I think why this is not possible for Microsoft has been explained.thoroughly in the past. It mostly has to do with licensing issues but seriously I think we should focus on finding realistic solutions or workarounds

I don't think that will ever happen. But tbh i don't even know what is the
endgame here. This is clearly targeted at developers, i dont know who wants
to use this, this is clearly so slow that nobody in the right mind would
use this. You are better of straight using a virtualbox if you want to use
a windows as your main os or what i have done just switch to linux (except
for a surface i have a linux and macos laptop)
And i would love to use windows, onenote is that important to me but this
is not everyday usable for me, i dont want ro pull my hair out when i use
git, and it adds seconds to every time i have to restart a web server and
so on. For some languages where that is not required like php it could work
but for my usecase it's to slow. and after reading a microsoft employee
response about hard limitations that they are hitting i dont know will it
anytime soon be better.
On Thu, Apr 9, 2020, 09:01 IOWEB TECHNOLOGIES<EMAIL_ADDRESS>wrote:

Guys, I think the only solution for this problem is re build a new Windows
11 based on Unix like mac does.
I think why this is not possible for Microsoft has been
explained.thoroughly in the past. It mostly has to do with licensing issues
but seriously I think we should focus on finding realistic solutions or
workarounds
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/WSL/issues/4197#issuecomment-611365611, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQNFZBX6K6BVWTTD24ZVZ3RLVXEZANCNFSM4HZN27MA
.

@anedisi As explained, moving your repo to the Linux file system solves this problem for now (and its's fast!). If you want fast access from another drive, the suggestion from @onomatopellan is a viable solutions. I managed to get this working quite easily with a little script (as root) that I run when I need acces from another drive, it spins up the mount (as described by @onomatopellan) and removes it when no longer used.
Powershell:
$timeoutSeconds = 5
$j = Start-Job -ScriptBlock {
    wsl -d Ubuntu-18.04 -u root;
}

Wait-Job $j -Timeout $timeoutSeconds | out-null

if ($j.State -eq "Completed") {
    wsl --terminate Ubuntu-18.04
} else {
    wsl --terminate Ubuntu-18.04
}

Remove-Job -force $j

I really don't know anything about Powershell, but this worked, so don't shoot me ;).
The only issue I have with this, for now, is the false advertising of: 'it's much faster'. Out of the box and using the windows drive mounts for development is clearly very slow... :(.

afaik i did that, its still slow when i access it from windows in the
editor. first git is slow from windows side and i want my GUI. the second
part is when i search for part of the code in the whole project. and the
third is the watcher that restarts the server when the file changes. its
changed from windows so that was having some problems. also the vm would
sometimes hang, for whatever reason, i just gave up because i did not have
time to debug more.
On Thu, Apr 9, 2020, 09:40 PVermeer<EMAIL_ADDRESS>wrote:

@anedisi https://github.com/anedisi As explained, moving your repo to
the Linux file system solves this problem for now (and its's fast!). If you
want fast access from another drive, the suggestion from @onomatopellan
https://github.com/onomatopellan is a viable solutions. I managed to
get this working quite easily with a little script (as root) that I run
when I need acces from another drive, it spins up the mount (as described
by @onomatopellan https://github.com/onomatopellan) and removes it when
no longer used.
Powershell:
$timeoutSeconds = 5$j = Start-Job -ScriptBlock {
wsl -d Ubuntu-18.04 -u root;
}
Wait-Job $j -Timeout $timeoutSeconds | out-null
if ($j.State -eq "Completed") {
wsl --terminate Ubuntu-18.04
} else {
wsl --terminate Ubuntu-18.04
}
Remove-Job -force $j
I really don't know anything about Powershell, but this worked, so don't
shoot me ;).
The only issue I have with this, for now, is the false advertising of:
'it's much faster'. Out of the box and using the windows drive mounts for
development is clearly very slow... :(.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/WSL/issues/4197#issuecomment-611380980, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQNFZG5E4PIJR7S3IIXSC3RLV3WZANCNFSM4HZN27MA
.

@PVermeer the suggestion was for my question to just store the filesystem data in another drive which could be useful in some use cases. For example I keep my data in a tripple mirror disk and I would like to store any project that's linux-only there.
What @anedisi is apparently interested in, is full 2-way communication from his windows side and the linux side which is in no way possible currently without being slow it seems.
I've also tried the solution with the empty linux instance and it is indeed writing fast to that area but when you access the mounts from windows side they're terribly slow as expected.
Basically as I understand it, any communication between the host (windows) and the client (wsl) has to be done via 9p protocol as mentioned by @SvenGroot so that's always going to be the case no matter what we try.
So the only working scenario so far is

Fast windows Access -> Slow Linux access
Fast Linux  Access -> Slow Windows Access

Doesn't help much in either case with the original goal of interop for developers in the current state. To be honest I don't see how Microsoft can bridge this gap in performance without ending up doing the same thing as they did in WSL1 as long as they rely on a protocol that doesn't suit the original purpose. It seems to me that a new need has appeared now to improve the protocol itself to suit WSL needs which probably isnt' going to happen.
Maybe I'm just jumping to conclusions but I don't think there's any light in the tunnel in this approach either. At least not in a short term.

@PVermeer Yet more easy, no need for PowerShell script thanks to WSL interop and wsl.exe nature.
No need to add anything in the external distro Alpine .profile either.
Just adding this to the Ubuntu .profile it mounts the external Alpine /home folder and exits automatically.
# mount external /home folder from Alpine distro
if [ ! -d /mnt/wsl/SHARED ]; then
    mkdir /mnt/wsl/SHARED
    wsl.exe -d Alpine mount --bind /home/ /mnt/wsl/SHARED/
fi

@onomatopellan Thanks! For now this will do.

The reason I'm asking this is because I'm redeploying a main machine with all tools installed every few weeks to multiple systems so I prefer to have all WSL instances on my main drive. However I would like to use a separate place for project files that will still reside in the "linux file system" but on a different physical disk location on the machine or an entirely different physical disk.

sudo su - root
dd if=/dev/null bs=1 seek=1024000000 of=/mnt/d/disks/xyz
mkfs.ext4 /mnt/d/disks/xyz
mkdir /home/user/xyz
mount /mnt/d/disks/xyz /home/user/xyz
chown user:user /home/user/xyz

1024000000 = 1GB
You can use 100GB + compress file in windows

Does cifs work accessing via a windows share in WSL?
Thinking of just adding an option to check/mount my ~/src in windows to my ~/src inside WSL2.

We are also looking at alternatives to 9p and other improvements we could make to get us closer to at least WSL1 DrvFs performance. And that work is going on in parallel with ongoing efforts to make IO performance in Windows better in general, which we would also benefit from of course.

Would that be virtio-fs? Perhaps even with dax?

@SvenGroot could you look at https://github.com/microsoft/WSL/issues/4197#issuecomment-613967720 ?

@SvenGroot Thank you for your really helpful comment and the given insight into the challenges you are having. :)

We already have an improvement in the pipeline that will reduce the round-trip cost significantly.  Unfortunately, despite our best efforts, that improvement was not ready for the upcoming 2004  release of Windows.

Is there already a timeframe or a possible insider release with this improvement on the horizon? Specifically: Can you say, if this improvements will be available with the Win10 20H2 release?

For anyone else landing here from Google:
WSL or WSL2 is not the problem: Which GIT you are using is the problem!
Use git.exe in /mnt/ and it's as snappy as you would expect.
See https://www.reddit.com/r/bashonubuntuonwindows/comments/evs4hr/do_you_like_using_wsl2_but_hate_how_slow_git_runs/

Ok but for me npm and sometimes even rm -rf is slow.

hello @jonpugh
Given the explanation here , if you use intensively the filesystem under /mnt you will has performance issue, that's not related to git, python3, go, node, dotnet, java, ...
you need to install these properly for the OS you are going to just like the post you pointed
Move out of /mnt if you can. Toying with tool cross filesystem and cross OS over /mnt is probably a source of the issue, not git by itself (the hack based on /pwd will "help" but be still be very limited to only git)
I'm curious why you would need to do intensive git action of the same repository and have that local repository shared over /mnt
Do you have a limitation that "blocks" you you to clone the repo on both filesystem ?
Also doing that and using npm this is a source of another level of bugs. The node_modules will be installed for the OS that ran the npm install.
fsevent will not "be the same" (or exists) on iOS/Linux/Windows etc ...

Not sure, but I think is better if we think that WSL2 is like just another network computer.
and yeap, you can read/write very fast in that machine, but if you try to use that network machine to connect to your initial machine to read/write files there... well, that is slow thing to do.
now, WSL2 is not another network machine, so, maybe is possible to create a internal port, but, then we will need a "translator" that listen Linux and write Windows. then this is expensive too, I think.
(and is not only that, is ensure to protect this powerful source of exploits)
I'm not an expert, this is just my opinion, but will be nice to explore a possible windows installer that works on partitions with Linux File System. just like an option, you can use your regular NTFS or SWAP.
maybe to use the same file system make this process easier, and some other extra benefits of use SWAP.

@tebeco

Do you have a limitation that "blocks" you you to clone the repo on both filesystem

I'm not @jonpugh but it's a lose-lose situation for me. If I clone my repo somewhere under Linux and try to open it with my IDE on Windows then my IDE will be slow. If I keep the repo under Windows, then my linux tooling will be slow.
The only thing that mostly works in VS Code running under Windows w/ the Remote - WSL extension and the repo under linux.
An alternative to the
if pwd | grep /mnt/c > /dev/null; then

hack that I came up with is:
alias node='$([ "$(stat -f -c %T .)" = "v9fs" ] && printf "node.exe" || printf "node")

This will work no matter where your mount is or how many drives you have. Unless maybe you have some other v9fs file system that isn't Windows. It returns ext2/ext3 on the linux side for me.
But again, to be clear, this is a hack and in no way solves the problem. Might even create more issues.
I'm trying to learn Powershell now so I can avoid this altogether. Powershell 7 has the && and || operators now, so that's nice.

To provide another use case:
I use a single maven repository that's shared between WSL and windows to eliminate duplicate jars. The repository is referenced with /mnt/c/[...]. WSL2 has made this solution unusable, and I have to use cmd.exe /c mvn [...] to get anything compiled.

I am also facing an issue which may be related to this one.
I try to do an SVN operation into my D drive (/mnt/D), as the repo contains some filename which is not friendly, so I have to do it inside a WSL.
Before I upgrade to WSL2, it works perfectly for a few months.
I have just updated to wsl2 and perform the SVN up, then I  have the disk io issue, and the svn sqlite3 database became malformed. The svn cleanup cannot fix it. I have tried to remove the SVN folder and try to pull it again, but I face disk io issue all the time. The SVN is around few Gb, and it failed randomly after 5 min. I have more than 100G in the harddisk.

To provide another use case:
I use a single maven repository that's shared between WSL and windows to eliminate duplicate jars. The repository is referenced with /mnt/c/[...]. WSL2 has made this solution unusable, and I have to use cmd.exe /c mvn [...] to get anything compiled in a reasonable amount of time.

@joseph-so I know that this is not an ideal solution, but I found that symlinking ~/.m2 in WSL to help here:
ln -s ~/.m2/ /mnt/c/Users/foo/.m2

Then I do a 1 time mvn clean install to cache my packages in windows. Subsequent mvn ... commands from linux run at an almost acceptable speed because all caching has been done.
Not perfect, but may help in the short term

@nmiodice ,
Thanks for your suggestion, but I want the data to store in my HDD instead of SDD (which your command is linking the folder to the a harddisk folder). I have tried to create a link and then do the SVN, but I have faced the same issue.
 I am thinking if it is possible to mount a vhdx in ext4 which stored in my harddisk as a temp solution (as I will only access it via the WSL), but I just cannot find a way to mount the vhdx in WSL, found some linux command/packages, but it seems they are not working well in WSL as there is nothing in /boot , so those command does not know what to do (based on the error message)

I am thinking if it is possible to mount a vhdx in ext4 which stored in my harddisk as a temp solution

https://github.com/microsoft/WSL/issues/4197#issuecomment-612438790

I am thinking if it is possible to mount a vhdx in ext4 which stored in my harddisk as a temp solution

https://github.com/microsoft/WSL/issues/4197#issuecomment-612438790

@alekseymvt Thanks a lot. It works and I can check out the SVN without issue (and the speed is fast)
Just one more question, do you know let WSL to auto mount it everytime?
Thanks

do you know how to let WSL automount it every time?

Sorry, I do not know the answer.
I just make run.sh
mount ... ... &&\
mount ... ... &&\
...
service nginx start &&\
service postgresql start &&\
service ssh start

And run it every time I start a wsl.
sudo ~/run.sh

@joseph-so @alekseymvt
You should be able to create a cmd file and put it in your user's startup that runs wsl -e "~/run.sh"

Alternatively, have your ~/,bashrc script check and run/start things for you... you'd still need to open a wsl prompt though.

@joseph-so I prefer the method the Docker team is using to attach and expose a vhdx to the WSL2 VM. I already explained it in this thread but maybe the post was confusing. Here it is:
How to automount external VHDX in WSL2
I have been used this method for weeks and it works great.

Thanks a lot, but @tracker1  / @onomatopellan  - for the wsl command do you run in Windows or in WSL?
After I have upgraded to WSL2, I cannot run the Windows command (like VS Code ) in WSL 1 ... (in past  I can use code . to load the folder). I have tried to enter wsl or wsl eve in the WSL, but it did not know what it is

@joseph-so which distro are you running? You need to call wsl.exe from inside WSL2. For that you need to have mounted /mnt/c and have /mnt/c/WINDOWS/system32 on the bash PATH.
This is my PATH that also can use code-insiders .
$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/ProgramData/chocolatey/bin:/mnt/c/Users/onoma/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/onoma/AppData/Local/Programs/Microsoft VS Code Insiders/bin:/snap/bin

@onomatopellan I am use OpenSUSE-Leap-15.1
I try to go to /mnt/c/WINDOWS/system32 and then run wsl.exe , but it is also failed

@joseph-so On OpenSUSE I just tried /mnt/c/Windows/System32/wsl.exe --help  and it works. It's case sensitive.

@onomatopellan Thanks, I found the issue, if I go to dir, it fails
jso@VivoMini-VC65:/mnt/c/Windows/System32> pwd /mnt/c/Windows/System32 jso@VivoMini-VC65:/mnt/c/Windows/System32> wsl.exe If 'wsl.exe' is not a typo you can use command-not-found to lookup the package that contains it, like this:     cnf wsl.exe jso@VivoMini-VC65:/mnt/c/Windows/System32> wsl.exe --help If 'wsl.exe' is not a typo you can use command-not-found to lookup the package that contains it, like this:     cnf wsl.exe jso@VivoMini-VC65:/mnt/c/Windows/System32>
but if i run /mnt/c/Windows/System32/wsl.exe --help, it works...
I need to try to figure out why my path did not have all of the path
Thanks

@joseph-so I'll post on my gist how to automount VHDX on OpenSUSE. There is some problem and doesn't add the Windows PATH.

@onomatopellan thanks a lot

For anyone else landing here from Google that is only seeing performance issues when running git commands:
WSL or WSL2 is not the problem: Which GIT you are using is the problem!
Use git.exe in /mnt/ and it's as snappy as you would expect.
See https://www.reddit.com/r/bashonubuntuonwindows/comments/evs4hr/do_you_like_using_wsl2_but_hate_how_slow_git_runs/
This replacement git script fixed it instantly!
https://gist.github.com/jasonboukheir/3fdab92ece236744528447a4f7f5de00
#!/bin/sh

if pwd | grep /mnt/c > /dev/null; then
    exec git.exe "$@"
else
    exec /usr/bin/git "$@"
fi

This defeats the purpose of using Wsl in the first place. If I run the Windows git executable for example my ssh keys from wsl are not used.

Thanks, @onomatopellan @tracker1 and @alekseymvt
Finally, I end up with using ./bashrc with
if ! grep -q "<My_Mount_Driver>" /proc/mounts; then         sudo mount <vhds_location> <My_Mount_Driver> &> /dev/null fi
(Need to add my own to sudo with noPassword to do that)
I would like to use @onomatopellan to mount the VHDX directly without a docker image, but fail .. the wsl command already complain my mount location is not a directory
I have tried the svn command multiple time (Delete the whole svn directory and then reclone it ) , an no issue so far

Sorry to pollute this thread, but I just finished installing a brand new Windows machine (with a Ryzen 3900x CPU, so it's blazing fast). After enabling WSL2 I saw that the git usage was fine until I put my saved .gitconfig under ~/.gitconfig - that's when it became veeeery slow again. Removing the ~/.gitconfig file made it fast again...
 Try to specify all the steps, windows build, shell used...etc.

Yeap, simple git status for me takes like 2 minutes while in Linux machine, same git status on same code would take like 2 seconds.

Seeing the same issue with rsync being a lot more slower on WSL2 compared to WSL1.

I have a same issue from a Java build with Maven.
From Windows my build is done in 57s but from WSL (in dedicated Java and Maven) and from the same folder (/mnt/c), the same build is done is nearly 15 minutes! :( :(l

ask you IDE editor to support the same feature as "Wsl remote"
VsCode properly works for dotnet/node/npm accross wsl directly
Makes it possible to work in wsl user folder and as explain in this thread ... stop working on /mnt/c
(Not tested but I think it works too in Vs2k2019)
I believe that if vscode managed to do it in electron/js/node it's probably something possible for heavier IDE (like IntelliJ) I suppose
Check out "Remote dev pack" extension
Your git repo will be on linux partition
that also fix the git status issue

+1
For embedded tooling it's really neat to compile in linux (WSL) and then flash debug from windows (Clion supports that for example). Cannot do that with VsCode because WSL doesn't have USB access. Really disappointed about that.

Debug from windows does work in such setup
so the relevant issue you spotted is the USB one if i understand correctly
so you choose to use a slow working directory in order to "workaround" the USB issue right ?

My use case is similar to others posting here. I store my project files on Windows filesystem and use WSL2 for command line operations. My IDE is performing well since its windows based but any CLI commands that affect multiple files are ridiculously slow.
A medium/large Git repository doing git checkout to switch branches takes 5+ minutes. git status takes comparable amount of time. If I run git on the windows side things are instant. This completely kills my WSL workflow. Is a fix being actively worked on for this problem? If I am go run my IDE on linux as well I may as well switch to Ubuntu and ditch windows altogether.

i updated win10 to 19041, and did a speed test on /mnt/c between a wsl2 vm and a virtualbox vm.

Also got the same problem. I've updated to WSL 2. Any actions with /mnt/* are extremelly slowly! It's not possible to use new version for this purposes.
How I cought, there isn't any solutions to fix it, is it?

@kovaldenys13 if you have to use something in both windows and linux nope, not yet.

My use case is similar to others posting here. I store my project files on Windows filesystem and use WSL2 for command line operations. My IDE is performing well since its windows based but any CLI commands that affect multiple files are ridiculously slow.
A medium/large Git repository doing git checkout to switch branches takes 5+ minutes. git status takes comparable amount of time. If I run git on the windows side things are instant. This completely kills my WSL workflow. Is a fix being actively worked on for this problem? If I am go run my IDE on linux as well I may as well switch to Ubuntu and ditch windows altogether.

@kyriakos Have quite similar workflow. Ended up having multiple shells - WSL1 and WSL2 and use WSL1 for all commands that are fast (or not so ridiculously slow) and if something is 100% not working in WSL1 shell - fallback to clumsy WSL2.
E.g running gradle is WSL1, invoking docker = WSL2
This may help you if you want to easily clone your existing WSL2 env into a copy and switch it to WSL1 (or vice versa)
https://twitter.com/centur/status/1265123336238989312

Thanks. It sounds good. I'll try it as alternative variant☺
пн, 1 Июн 2020, 3:35 Alexey Shcherbak<EMAIL_ADDRESS>
My use case is similar to others posting here. I store my project files on
Windows filesystem and use WSL2 for command line operations. My IDE is
performing well since its windows based but any CLI commands that affect
multiple files are ridiculously slow.
A medium/large Git repository doing git checkout to switch branches takes
5+ minutes. git status takes comparable amount of time. If I run git on
the windows side things are instant. This completely kills my WSL workflow.
Is a fix being actively worked on for this problem? If I am go run my IDE
on linux as well I may as well switch to Ubuntu and ditch windows
altogether.
@kyriakos https://github.com/kyriakos Have quite similar workflow.
Ended up having multiple shells - WSL1 and WSL2 and use WSL1 for all
commands that are fast (or not so ridiculously slow) and if something is
100% not working in WSL1 shell - fallback to clumsy WSL2.
E.g running gradle is WSL1, invoking docker = WSL2
This may help you if you want to easily clone your existing WSL2 env into
a copy and switch it to WSL1 (or vice versa)
https://twitter.com/centur/status/1265123336238989312
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/WSL/issues/4197#issuecomment-636556572, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AMYI6YPK5BJUFZTUSUCTS3LRULZWVANCNFSM4HZN27MA
.

What's the official statement on this subject? Is there a plan to improve this use case or it's recommended to go back WSL1?

The issue is that this post is filled with lots of (negative ?) comments just stating the same thing over and over again.
As this is a real struggling issue, maybe you would have seen both this post:
https://github.com/microsoft/WSL/issues/4197#issuecomment-568923487

But now this happen:

So you can't see one of the constructive statement / detailed technical answer:
https://github.com/microsoft/WSL/issues/4197#issuecomment-604592340
(Can't fit in one screen)

The end result is that nobody can keep track of anything in this post anymore and starts to unsubscribe making it a bit useless ... "A yes we know there is a problem"

Would someone be willing to create and manage an issue with all the workarounds mentioned in here for optimizing the workflow when possible? What makes you think that the new issue won't be polluted like this one hiding all useful information? I guess I could edit the original post though to add Sven's response to the very top as a pointer

WSL2 is too slow to be useful for development with node on /mnt/ volumes.  yarn/npm install takes "forever" compared to git bash.

So basically WSL2 does not enable FS interop, unless for small read-only tasks, because performances are too slow. One has still to choose between Linux- or Windows-based workflows, otherwise the performance penalties is too much a barrier to work decently.
Is there any plan to make a more seamless interoperability available?
I am a bit disappointed 😞 , but at least working on the linux side of WSL2 has now better performances & docker support

@lamuertepeluda
the answer 2 post up here : https://github.com/microsoft/wsl/issues/4197#issuecomment-637333045 has the link to the answer you are looking for

Ok so, given what is well-explained in the comment above ❤ , the only solution I can imagine to this issue and to achieve a real fs interoperability would be adding full support (read-write) for a Linux File System in the Windows Kernel/IO System, and then share this Linux partition (e.g. a ext4 partition) between Windows and the VM(s). No emulation, no copying files.
I also understand that this could have potentially a lot of downsides for supporting some Windows apps that rely on NTFS, or break something else, or bring some security issues I cannot foresee.

Ok so, given what is well-explained in the comment above ❤ , the only solution I can imagine to this issue and to achieve a real fs interoperability would be adding full support (read-write) for a Linux File System in the Windows Kernel/IO System, and then share this Linux partition (e.g. a ext4 partition) between Windows and the VM(s). No emulation, no copying files.
I also understand that this could have potentially a lot of downsides for supporting some Windows apps that rely on NTFS, or break something else, or bring some security issues I cannot foresee.

In practice you can't have two operating systems mount the same local filesystems at the same time. All kind consistency guarantees get throw out the window.
I think implementing support for virtio-fs looks like a good approach but of course I have no idea how viable it is to get Hyper-V to support it.

It would seem that lots of people want to edit their projects on windows
(VSCode, IntelliJ etc) and then compile/build on Linux. So one of the
solutions would be to expose the working Linux dir as an SMB mount for
windows, edit files there (it won't matter if SMB is slow here), and then
do compilation/building on WSL. Basically, do the reverse network FS.
On Wed, Jun 3, 2020 at 11:47 AM Vito Macchia<EMAIL_ADDRESS>wrote:

Ok so, given what is well-explained in the comment above
https://github.com/microsoft/WSL/issues/4197#issuecomment-637333045 ❤
, the only solution I can imagine to this issue and to achieve a real fs
interoperability would be adding full support (read-write) for a Linux File
System in the Windows Kernel/IO System, and then share this Linux partition
(e.g. a ext4 partition) between Windows and the VM(s). No emulation, no
copying files.
I also understand that this could have potentially a lot of downsides for
supporting some Windows apps that rely on NTFS, or break something else, or
bring some security issues I cannot foresee.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/WSL/issues/4197#issuecomment-638087854, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAB4LMTITVQPA3IKVFCWJOTRUYL27ANCNFSM4HZN27MA
.

--
Kind Regards,
Tadas Šubonis

I can confirm that accessing any type of network share in intellij idea will cause tremendous slow downs in the IDE so they won't work

It would seem that lots of people want to edit their projects on windows (VSCode, IntelliJ etc) and then compile/build on Linux. So one of the solutions would be to expose the working Linux dir as an SMB mount for windows, edit files there (it won't matter if SMB is slow here), and then do compilation/building on WSL. Basically, do the reverse network FS.

This means the SAMBA service must be always running. Last time I checked with Docker service, it gets stopped after a while since I closed WSL window.
It all depends on how far WSL team wants this solution to go. They could get Windows Service architecture to manage Linux daemons. They could get Windows to support ext4 for WSL linux to mount directly. They could provide plugins to many IDEs to support remote development.
I think the cheapest solution is to fully support Linux GUI apps, which the team is working on. That way you can run Linux version of IDEs or what tools you need for work within WSL. You won't need interoperability. WSL is all you need.

tbh the only solution i see them implementing that could cover a lot of use cases and could be implemented in short term is the way vscode does it with a remote vscode, where there is a server running in a linux side that comunicates with windows side. if other IDE-s impelemnt the same thing (microsoft sure could sponsor something like that for major IDE-s). then we are stuck at git, npm and tools like that and for that the same could be done from other side. linux triggers the command, windows does it and then returns the output to linux. at least for those tools that are most used (and they have the data) this could be the way and for others let them run natively. to me it looks that for most of people in this issue that would be good enough

I think the cheapest solution is to fully support Linux GUI apps, which the team is working on. That way you can run Linux version of IDEs or what tools you need for work within WSL. You won't need interoperability. WSL is all you need.

This sounds great, but does not make a ton o business sense. Why would then anybody in small dev studio target windows when they can target macos and linux and for windows tell developers to run it in wsl2.
while that sounds silly now i don't think its something you can completely ignore.

I think the cheapest solution is to fully support Linux GUI apps, which the team is working on. That way you can run Linux version of IDEs or what tools you need for work within WSL. You won't need interoperability. WSL is all you need.

This sounds great, but does not make a ton o business sense. Why would then anybody in small dev studio target windows when they can target macos and linux and for windows tell developers to run it in wsl2.
while that sounds silly now i don't think its something you can completely ignore.

Yeah that's silly.
In my case I have to use Windows as there are apps do not provide Linux version.
Why not Mac? I'm a PC.

i'ts not really that silly just far fetched.
if i could target osx and linux and get windows for free as a first osx/linux developer i would probably do it.
and to be honest to me it looks like the whole WSL project was more targeted to developers that wanted to jump to osx from windows, or osx that wanted to try linux. i don't think the windows crew that has to stay on windows was the target of this project. microsoft is not some sort of charity, you have to look at everything from a business sense. also please sorry, i wont off topic anymore and spam your inboxes.

Just to let you know: I have the same problem with WSL2 using WordPress containers. A pageview in my simple website takes 8s, while in WSL it takes less than a second. That's why I turned back to WSL1.

I'm not sure it works directly. use msize as a tuning range for p9fs.
https://sourceforge.net/p/v9fs/mailman/ message/28595114/
https://www.kernel.org/doc/Documentation/ filesystems/9p.txt
msize=n the number of bytes to use for 9p packet payload
The drvfs (mount.drvfs) provided by wls2 will reflect the mount options, and the Not.
As far as the binary is concerned, it seems to be fixed at 64K (65536).
Because the storage performance of recent years is getting better, I think that the value should be a little larger or
I think it should be possible to specify it as an option.
/proc/mounts
name=drvfs ... msize=65536
In binary (/sbin/mount.drvfs)
/proc/sys/fs/binfmt_misc/register trans=fd, rfdno=%d,wfdno=%d,msize=65536,aname=drvfs; path=%s
potential bottleneck in msize option?

On WSL2: If I store my files on the Linux File System as proposed:

What is the most performant way to access and edit these files from IntelliJ?

I think this is the most common use-case for DEVs right now.

Run intellij in linux too and use some X server to show it. That'll give you the best IO performance currently available potentially at the expense of some UI performance.

Is there any method of running programs with e.g. vcXsrv seamlessly (without a windows chrome and without a virtual desktop over X Server?)
I just want to start single programs (like IntelliJ).

At some point it’s just not worth the hassle of running WSL.  Reboot to Linux and get back to work.

On WSL2: If I store my files on the Linux File System as proposed:

What is the most performant way to access and edit these files from IntelliJ?

I think this is the most common use-case for DEVs right now.

I access the files via \\wsl$\ and it works without any problems.

I access the files via \\wsl$\ and it works without any problems.

I just set the same thing up today, and it seems to be working OK too. The editor is a low bandwidth process, and probably won't be hit very hard even if it's not that performant.

I'm really scared about using \wsl$. My projects usually have 17k - 30k files with all vendor dependancies. Will the indexer suvive that?
Setting up an X Server just to run IntelliJ seems to me like the wrong approach. Is it even doable?

It is certainly possible but terrible too. You can use an x server like xming. Let me point a few issues with that

The first project you open located on a network drive like \wsl$  will slow down all other projects open in the IDE. It's a known issue in jetbrains bug tracker

You need a second license if you run it simultaneously with windows instances.

The indexer is very slow in \wsl$ as it seems it suffers from the same speed issues as drvfs in /mnt

Running jetbrains IDE in WSL is only good again for projects located in ~/

Wsl2 is simply not a usable solution when source needs to be synced on windows AND the Unix system.
My current setup is to use Docker-toolbox with VMware workstation. The speed is so much faster than wsl.
For even faster development I copy the vendor dir into the container (cause it does not change as much).  This is significantly faster then having vendor in mount bind.
I tried the same approach in wsl... little bit faster than normal wsl but still terrible.

My current setup is to use Docker-toolbox with VMware workstation. The speed is so much faster than wsl.

Care to explain this setup more in-depth please?

Adding my use case here. I've switched back to WSL1 on both a 6 core desktop 32GB ram and on a Surface Pro 8 core with 16GB ram. On WSL1 I have response times of 2-10s for a PHP-FPM/Nginx Laravel API. On WSL2 all requests timeout due to IO operations. I've had to switch back to WSL1 on all machines to be able to continue working.
A solution to this would be to enable direct block device mount (#689) for read/write in WSL such that:
/dev/sdaX is formatted in either NTFS or EXT4 (Using Paragon extX drivers for example)
/dev/sdaX on Windows is mounted at $DRIVE_LETTER:/
/dev/sdaX on WSL is mounted on /mnt/$FOLDER
Or simply an improvement in accessing Windows mounted filesystems for high IO operations under WSL. Great tool but WSL2 is not ready for developers requiring high performance.

On WSL2 all requests timeout due to IO operations.

Just move laravel project inside wsl2.

@ninjasitm

On WSL2 all requests timeout due to IO operations.

Just move the laravel project inside wsl2.

Its all a compromise between IDE performance and execution performance. Personally I use PHPStorm, keep project in wsl2 file system and IDE on Windows side. Indexing is very slow and new files aren't picked up immediately (PHPStorm sees wsl$ as a network path) but its a small price to pay for the shorter execution times.
Either way this is a well known issue by now I am pretty sure it must be high on Microsoft's priority list to fix so its a matter of waiting.

For anyone who struggling with cross-platform vscode + ms-vscode-remote.remote-wsl plugin, you have to create two workspaces, one for Windows repos + file editing and another one for WSL repos (I recommend rewriting all path to absolute paths). If you right click the vscode icon on taskbar and pin this two workspace there, at startup vscode will initialize the WSL remote connection when you choose WSL! This is huge time saver and makes multi environment less painful. You can keep the WSL workspace file on Windows host next to Windows one. It's not a huge file to have any performance issues.

One neat feature in MSYS2 if you put the Windows folder path within a quote, like $ ls -al "C:\Users\User", MSYS will translate the path to /c/Users/User. Unfortunately vscode can't do that. :( If you brave enough, you can add MSYS executible's folder to path, this way they can be used in batch scripts. I'm Cygwin -> MSYS2 user almost a decade and so far never had a "catastrophic failure" having all of these "Linux" apps in my path. If you want to have same "feel" with WSL, you can have batch scripts in your path like:
@ECHO OFF
wsl nano %*

With this, you can call > nano newfile.txt in your cmd. What you will see that you run nano in Command Line, but in reality it will run in WSL2 like normally would.
Keep in mind this solution have lots of compatibility issues with vscode plugins (like eslint), which likely not gonna work. That's why ms-vscode-remote.remote-wsl plugin is for. For piping CLI output though, I think it's gonna work.

Regarding the conversation that is WSL2 suitable for "moving all of your dev stuff into WSL", I think it's almost there, but not quite there yet. The biggest problem is not with WSL2's design, it's within the "cross platform reproducable dev environment" paradigm. That is why Vagrant + Virtualbox created on the first place.
Regarding the development tools that you need to keep on your host Windows, I think most devs what really want is not platform agnostic development, it's easier tool maintenance, aka: a proper package manager! WinGet (formerly AppGet) is a good addition, but needs lot of time to become a great one. This tool not a package manager, it should be called "INAPGI" (I'm not a Package Manager, Get it!?). It installs stuff and honestly this would be enough, if it can update those programs, but it can't. It's not a Chocolatey and it's not an AppGet unfortunately. We can hope it will become one day that is intended to be.

Thanks to all providing alternatives and suggestions to increase the performance using WSL2.
We had suggestions like the following multiple times in this issue:

On WSL2 all requests timeout due to IO operations.

Just move the laravel project inside wsl2.

But that's like suggesting to use a car of someone asks for bike lanes.
It es an alternative, but not a good one, and not something you "just" do.
Getting a good performance for e.g. web development with WSL2 atm requires a very specific and annoyingly restricting development setup, which a lot of people are not willing to use.
I'd rather move a away from Windows completely, if I'd be willing to change my development setup in such a drastic way.
I'm hoping there will be improvements in this area soon.
Until then Docker Desktop with Hyper-V seems to remain the best option for web development on Windows with focus on flexibility and acceptable performance and stability.

I'm also not happy with this half-baken solution.
I did a lot of research and found mutagen.io.
What about having the files inside the Docker Container WSL2 and syncing them to your lokal environment using mutagen sync? Dis someone try something like that?
Then we could have full speed of IntelliJ / PHPStorm and full IO speed inside the Docker Container. Syncing them with a short delay seems to be a ok-ish solution.

My current setup is to use Docker-toolbox with VMware workstation. The speed is so much faster than wsl.

Care to explain this setup more in-depth please?
@rfgamaral

Docker-Toolbox installes a VM on your computer in which docker runs.
I'm using the driver from @pecigonzalo (https://github.com/pecigonzalo/docker-machine-vmwareworkstation) to use VMware Workstation instead of VirtualBox.
Docker-Machine than uses boot2docker (https://github.com/boot2docker/boot2docker) to setup a running vm.
Your data (C:\users) is mounted via hgfs into the vm so u can access it.
It is basically the same approach as wsl2 uses, but hgfs is so much faster than whatever microsoft uses to mount the host data.

WSL2 uses plan9/9p

Does mutagen work bidirectionally? Let's say I run a git checkout in wsl2, then change a file in my ide on Windows side will both changes be synced in either directions?

I'm also not happy with this half-baken solution.
I did a lot of research and found mutagen.io.
What about having the files inside the Docker Container WSL2 and syncing them to your lokal environment using mutagen sync? Dis someone try something like that?
Then we could have full speed of IntelliJ / PHPStorm and full IO speed inside the Docker Container. Syncing them with a short delay seems to be a ok-ish solution.
My current setup on Windows is Vagrant, Virtualbox. For filesync I use NFS (WinNFSd plugin for Vagrant).

@kyriakos The documentation says yes even with conflict resolution.
Default is :
two-way-safe (Default): In this bidirectional synchronization mode, both endpoints are treated with equal precedence, and conflicts are only automatically resolved if they don’t result in data loss (for example, modifications on one endpoint can can overwrite deletions of the corresponding content on the other endpoint). If conflicts can’t be automatically resolved, they are stored in the session state (and can be enumerated with the mutagen sync list command).
https://mutagen.io/documentation/synchronization
But I have not tried it. It just seems like a possible solution for some of us.

Is there any plans to fix this? I mean, not by providing hacks to put this here and that there.

@erick2red, yes there actively working on it: check out this post from one of the WSL team members:
https://github.com/microsoft/WSL/issues/4197#issuecomment-604592340

Hi, I'm trying to do the UNC wsl approach to work win Intellij and have fast git but I can't even do that...

Do I need to activate something so that I can see those network paths. The curious thing is that I can do cd \\wsl$\Ubuntu from powershell and it gets in. But if I do explorer.exe . it shows me the Windows Documents folder... Any ideas?

Is there a recommended workflow for WSL2 and Visual Studio 2019 to get around this issue? I'm using docker via WSL2 which works great for smaller projects + VS Code remote, but not large projects + VS2019.
If I have my project code in ~/projects, map \wsl$\Ubuntu-20.04 to Z: I can open the solution in VS2019 but then every file operation the IDE does (indexing, searching, building) is really slow, the editor is semi-usable if I disable the VS2019 version control plugin but still far from a smooth  experience.
If I have my project code in %userprofile%\source VS2019 is (of course) fine, but any external WSL2 tooling I want to use (i.e. Docker) is painfully slow.
How are people working with docker (wsl2) + Visual Studio 2019?

How are people working with docker (wsl2) + Visual Studio 2019?

The only way I have gotten this to work acceptably well with Docker is to put the code onto WSL, then point your IDE to the code in WSL via a mount, so under \\wsl$\. Then you run the docker run or docker-compose or whatever tools to launch Docker, within WSL. This keeps all the code, and runtime on WSL side, and you edit on the Windows side.
It's blazing fast for me.

@zakeryooo My alternative is to write code in WSL2( \wsl$\Ubuntu) directly. It is much more  faster than before.

That's what I'm doing (option #1 in my original post), but then editing & building on the Windows side (i.e. with Visual Studio) slows to a crawl with projects of any real size because of the slow ext4 file access from Windows.

WSL seems aimed at developers who want to live in a Linux environment while working in an organization where Windows is the dominant OS, once in a while using Windows applications.  That means most people will generate files on a Windows native file system and there will be remote Windows servers which must be accessed as well.  Files must be written to Windows file systems for sharing and collaboration.  Therefore, access to /mnt/c and \server\share directories must be fast and replication of files onto Linux native file systems is not a solution due to potential synchronization issues.  That is why there are so many messages here and regardless of the complexity of the problem, a reasonably performant solution is required.
For those who mainly use Windows apps/tools and once in a while want to use Linux tools, there is little need for WSL, just use Windows compiled binaries of Linux commands and/or a Windows X Server.

@rswdp It may be shocking to hear this (forgive the joke), but some people prefer windows 10 to Linux...
I don't mean to be snarky or rude - I have multiple desktop systems and I am free to choose the OS, and I chose windows 10 professional. Even paid for the license!
I might have changed to linux, but WSL eliminates that need :) Not everyone is a hostage!

I've just faced this very issue myself. Got some gradle based Java project that builds about 7 jars.
When code is on the / mount building all of them takes 33 seconds.
When code is inside /mnt somwhere, build of all jars takes 19 minutes!
Guys, this isn't even funny. Who at MS thought that WSL 2 is ready for shipping in this state? It's not. It's unusable.

I've just faced this very issue myself. Got some gradle based Java project that builds about 7 jars.
When code is on the / mount building all of them takes 33 seconds.
When code is inside /mnt somwhere, build of all jars takes 19 minutes!
And it's all on PCI-E 4.0 NVMe SSD drives with a Threadripper 3970x CPU.
Guys, this isn't even funny. Who at MS thought that WSL 2 is ready for shipping in this state? It's not. It's unusable.

I think that the best thing you can do at this stage is get an x11 server and bootstrap intellij inside wsl, it would the the closest to native experience but it's a pain we have to do stuff like that.