Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ioweb-gr opened this issue Jun 19, 2019 · 381 comments
Open

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

ioweb-gr opened this issue Jun 19, 2019 · 381 comments

Comments

@ioweb-gr
Copy link

@ioweb-gr ioweb-gr commented Jun 19, 2019

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: #4197 (comment)_

@billziss-gh
Copy link

@billziss-gh billziss-gh commented Jun 20, 2019

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.

@ioweb-gr
Copy link
Author

@ioweb-gr ioweb-gr commented Jun 20, 2019

I see,

I'm assuming you're still refering to / and not /mnt folders about namespace operations.
I've repeated the write tests in both environments a few times now and there's no consistent result.

WSL 2

root@LUCIANO-PC:/home/# dd if=/dev/zero of=/testfile bs=1M count=10000
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.

@paultyng
Copy link

@paultyng paultyng commented Jul 12, 2019

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

@definelicht
Copy link

@definelicht definelicht commented Jul 16, 2019

I'm experiencing the same issue, /mnt is extremely slow compared to WSL1 (seconds to run git status on a relatively small repository).

@paultyng
Copy link

@paultyng paultyng commented Jul 18, 2019

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

@ioweb-gr
Copy link
Author

@ioweb-gr ioweb-gr commented Jul 19, 2019

This is an example from the command

pv files.tar.gz | tar -zxf -

The speed is amazingly slow in wsl2 on /mnt

image

@definelicht
Copy link

@definelicht definelicht commented Jul 22, 2019

Do we know what's at the root of this, and whether there are any other workarounds than downgrading?

@benhillis
Copy link
Member

@benhillis benhillis commented Jul 22, 2019

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

@ioweb-gr
Copy link
Author

@ioweb-gr ioweb-gr commented Jul 27, 2019

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

@tuananh
Copy link

@tuananh tuananh commented Aug 12, 2019

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

@definelicht
Copy link

@definelicht definelicht commented Aug 12, 2019

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

@tuananh
Copy link

@tuananh tuananh commented Aug 14, 2019

@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

@gbatalski
Copy link

@gbatalski gbatalski commented Aug 15, 2019

can confirm a very bad performance on /mnt (mvn install takes forever), on /tmp it takes only 2 minutes for the same project

@nono-pxbsd
Copy link

@nono-pxbsd nono-pxbsd commented Sep 11, 2019

After switch configuration from WSL to WSL 2 (Build 18975), without any change on my distro, the server respond time incresed.

Configuration : Debian buster Apache2.X / PHP-FPM 7.3 / MySQL
Root : /
Web directories : /c/repositories/xxx

WSL 1 : 0.5 sec
WSL 2 : 8 sec

With Docker (Ubuntu 18.04) WSL Tech preview i could not test on WSL 1, but WSL 2 takes over 30 sec... I suppose the issue is the same.

@realtica
Copy link

@realtica realtica commented Sep 13, 2019

This is my performance in a medium project:

GIT_TRACE_PERFORMANCE=1 git status -sb -uno

13:20:04.630972 read-cache.c:2267 performance: 0.017249300 s: read cache .git/index
13:20:07.766270 preload-index.c:146 performance: 3.135180100 s: preload index
Refresh index: 100% (3463/3463), done.
13:20:53.531359 read-cache.c:1575 performance: 48.900269600 s: refresh index
13:20:53.981829 read-cache.c:2267 performance: 0.016242500 s: read cache /mnt/e/p/keyed_au/.git/ modules/Files/media/nusoap/index
13:20:54.383135 read-cache.c:1575 performance: 0.401222700 s: refresh index
13:20:54.426399 diff-lib.c:251 performance: 0.000005000 s: diff-files
13:20:54.468000 unpack-trees.c:1554 performance: 0.000087700 s: traverse_trees
13:20:54.468266 unpack-trees.c:465 performance: 0.000164900 s: check_updates
13:20:54.468346 unpack-trees.c:1649 performance: 0.000438000 s: unpack_trees
13:20:54.468368 diff-lib.c:537 performance: 0.001873400 s: diff-index
13:20:54.569793 read-cache.c:2989 performance: 0.014679900 s: write index, changed mask = 2
13:20:54.586550 trace.c:477 performance: 0.736638600 s: git command: /usr/lib/git-core/git status --porcelai n=2 -uno
13:20:55.277184 read-cache.c:2267 performance: 0.031572000 s: read cache /mnt/e/p/keyed_au/.git/ modules/Files/modules/unittest/index
13:20:55.958706 read-cache.c:1575 performance: 0.681302500 s: refresh index
13:20:56.007094 diff-lib.c:251 performance: 0.000003500 s: diff-files
13:20:56.041768 unpack-trees.c:1554 performance: 0.000081200 s: traverse_trees
13:20:56.042014 unpack-trees.c:465 performance: 0.000162100 s: check_updates
13:20:56.042084 unpack-trees.c:1649 performance: 0.000399800 s: unpack_trees 13:20:56.042102 diff-lib.c:537 performance: 0.000454400 s: diff-index 13:20:56.126615 read-cache.c:2989 performance: 0.012095500 s: write index, changed mask = 2 13:20:56.141174 trace.c:477 performance: 1.261971900 s: git command: /usr/lib/git-core/git status --porcelain=2 -uno 13:20:56.148677 diff-lib.c:251 performance: 2.586112000 s: diff-files 13:20:56.190888 unpack-trees.c:1554 performance: 0.000022200 s: traverse_trees 13:20:56.191028 unpack-trees.c:465 performance: 0.000027800 s: check_updates 13:20:56.191106 unpack-trees.c:1649 performance: 0.000639200 s: unpack_trees 13:20:56.191175 diff-lib.c:537 performance: 0.001413100 s: diff-index
13:20:56.215068 trace.c:477 performance: 51.628126000 s: git command: git status -sb -uno

File System exFat, the result is the same is other file system...
WSL 2 git=51.62 sec
git for windows=0.8 sec

@paslandau
Copy link

@paslandau paslandau commented Sep 15, 2019

I'm currently using the normal Docker Desktop with linux containers to run a PHP projekt during local development. The repo is in a normal Windows directory and gets mounted via volume bind in the docker container, so that I can easily manipulate the files through an IDE.

The same setup on a native linux machine has always been multiple times faster and the "problem" (from what I've read) has always been attributed to the Linux VM that is used on Docker Desktop.

Then WSL 2 was announced and I finally came around to set everything up. But when I ran our teststuite for the first time, I was pretty disappointed that the performance was actually much worse than before (40s on the Docker Deskop Linux VM setup vs 100s on the WSL2 setup). Subsequent investigation brought me to this thread.

From what I've read here so far:

Does it even make sense to switch to WSL 2 for local development yet if "bad performance" is your primary reason to do so?

A "no" would be a totally acceptable answer - I just don't want to waste any more time on this if it's simply not ready yet.

@stweedie
Copy link

@stweedie stweedie commented Sep 19, 2019

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?

@gormulent
Copy link

@gormulent gormulent commented Sep 24, 2019

I'd also like to ask about this, doing a git status on something in /mnt/c/.. takes about a minute, something seems wrong ..

@gbatalski
Copy link

@gbatalski gbatalski commented Sep 27, 2019

same with 1903 (18990.1) absolutely useless...

@wusticality
Copy link

@wusticality wusticality commented Sep 27, 2019

I am also seeing this, accessing Windows files from the Linux environment is several orders of magnitude slower in WSL2 than in WSL1.

@adipose
Copy link

@adipose adipose commented Oct 27, 2021

@jgwinner
Copy link

@jgwinner jgwinner commented Oct 28, 2021

It's hard to find a year old comment in 300+ comments )

Which is why it's linked at the very top as the current status.

the binary patching for that issue suggests it's not simple to make custom changes.

Agreed. The current status explains why it's hard - there are multiple VM layers, etc. Read the post, it's quite informative.

I'm frustrated as well, which is why I subscribed, but some things aren't trivial.

@adipose
Copy link

@adipose adipose commented Oct 28, 2021

It's hard to find a year old comment in 300+ comments )

Which is why it's linked at the very top as the current status.

the binary patching for that issue suggests it's not simple to make custom changes.

Agreed. The current status explains why it's hard - there are multiple VM layers, etc. Read the post, it's quite informative.

I'm frustrated as well, which is why I subscribed, but some things aren't trivial.

Well, yes, but clearly Microsoft has way more resources to fix it, publish it, and take advantage of closed windows apis than a random github poster. Linux being open source seems pretty irrelevant to that.

@pihish
Copy link

@pihish pihish commented Nov 13, 2021

I cant tolerate it, so I just test the mutagen alternative fix.

Here is the fix based on mutagen: I wrote the docs here, and tested it, it works great.

https://j0eii.cwh-labs.com/wsl2-extremely-slow-file-read-fix-mutagen/

It really been a long long time for this one. Thanks @kyriakos for the issue fix suggestion, and Microsoft for providing WSL2 docker, and everyone whom discussed this issue fix.

@j0eii Currently following the guide you linked to. On step 4, where are you creating the docker-mirrors directory? Is this in the Docker session or the Windows machine?

@j0eii
Copy link

@j0eii j0eii commented Nov 13, 2021

I cant tolerate it, so I just test the mutagen alternative fix.
Here is the fix based on mutagen: I wrote the docs here, and tested it, it works great.
https://j0eii.cwh-labs.com/wsl2-extremely-slow-file-read-fix-mutagen/
It really been a long long time for this one. Thanks @kyriakos for the issue fix suggestion, and Microsoft for providing WSL2 docker, and everyone whom discussed this issue fix.

@j0eii Currently following the guide you linked to. On step 4, where are you creating the docker-mirrors directory? Is this in the Docker session or the Windows machine?

image
Nice, it should be on wsl2 <3

@pihish
Copy link

@pihish pihish commented Nov 13, 2021

I cant tolerate it, so I just test the mutagen alternative fix.
Here is the fix based on mutagen: I wrote the docs here, and tested it, it works great.
https://j0eii.cwh-labs.com/wsl2-extremely-slow-file-read-fix-mutagen/
It really been a long long time for this one. Thanks @kyriakos for the issue fix suggestion, and Microsoft for providing WSL2 docker, and everyone whom discussed this issue fix.

@j0eii Currently following the guide you linked to. On step 4, where are you creating the docker-mirrors directory? Is this in the Docker session or the Windows machine?

image Nice, it should be on wsl2 <3

@j0eii Is WSL2 the same thing as the Docker instance or is it a separate instance?

@j0eii
Copy link

@j0eii j0eii commented Nov 13, 2021

I cant tolerate it, so I just test the mutagen alternative fix.
Here is the fix based on mutagen: I wrote the docs here, and tested it, it works great.
https://j0eii.cwh-labs.com/wsl2-extremely-slow-file-read-fix-mutagen/
It really been a long long time for this one. Thanks @kyriakos for the issue fix suggestion, and Microsoft for providing WSL2 docker, and everyone whom discussed this issue fix.

@j0eii Currently following the guide you linked to. On step 4, where are you creating the docker-mirrors directory? Is this in the Docker session or the Windows machine?

image Nice, it should be on wsl2 <3

@j0eii Is WSL2 the same thing as the Docker instance or is it a separate instance?

docker is a dependent instance running on both ws2 and windows , which can be used as a io bridge in this case as a alternative fix. you need to install windows docker first in order to use this solution.

@mrjrieke
Copy link

@mrjrieke mrjrieke commented Dec 14, 2021

Not sure if this is related at all. I have a command line tool that works off a directory of files. If I create a symlink via:
ln -s source newdir

Then, run the tool against the new symlink dir instead of the actual source dir, I get a significantly slower run of the tool.

I know this doesn't happen on raw linux.

By build:
uname -a
Linux 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 GNU/Linux

@robertwt7
Copy link

@robertwt7 robertwt7 commented Feb 9, 2022

I cant tolerate it, so I just test the mutagen alternative fix.

Here is the fix based on mutagen: I wrote the docs here, and tested it, it works great.

https://j0eii.cwh-labs.com/wsl2-extremely-slow-file-read-fix-mutagen/

It really been a long long time for this one. Thanks @kyriakos for the issue fix suggestion, and Microsoft for providing WSL2 docker, and everyone whom discussed this issue fix.

I have to save this comment. this is an amazing docs. Maybe as an alternative MS should document this issue?

Some of us still relies on windows drive to properly organize our project files :)

@j0eii
Copy link

@j0eii j0eii commented Feb 11, 2022

I cant tolerate it, so I just test the mutagen alternative fix.
Here is the fix based on mutagen: I wrote the docs here, and tested it, it works great.
https://j0eii.cwh-labs.com/wsl2-extremely-slow-file-read-fix-mutagen/
It really been a long long time for this one. Thanks @kyriakos for the issue fix suggestion, and Microsoft for providing WSL2 docker, and everyone whom discussed this issue fix.

I have to save this comment. this is an amazing docs. Maybe as an alternative MS should document this issue?

Some of us still relies on windows drive to properly organize our project files :)

Thank you for your inspiring compliment. I am glad to hear that you liked my work.

@Bilal-io
Copy link

@Bilal-io Bilal-io commented Mar 6, 2022

If I create a symlink via:
ln -s source newdir

That's the same case for me. As a workaround I will continue to work with the /mnt/c/dir directly for now, until there is a better solution.

@rPraml
Copy link

@rPraml rPraml commented Apr 8, 2022

I tried to use NFS to share my WSL home with windows

In WSL I've installed nfs with sudo apt install nfs-kernel-server
On Windows, you need to enable/install "Client for NFS" https://graspingtech.com/mount-nfs-share-windows-10/

Then I've the following script, which starts rpcbind/nfs and mounts the E drive to home directory

#!/usr/bin/env bash
/mnt/c/windows/system32/umount.exe -a
echo "$HOME/dev   172.16.0.0/12(rw,async,all_squash,no_subtree_check,fsid=0,anonuid=1000,anongid=1000)" | sudo tee /etc/exports
sudo mkdir /run/sendsigs.omit.d
sudo /etc/init.d/rpcbind restart
sudo /etc/init.d/nfs-kernel-server restart
IP=`ip -o route get to 8.8.8.8 | sed -n 's/.*src \([0-9.]\+\).*/\1/p'`
/mnt/c/windows/system32/mount.exe -o anon,lang=UTF-8 \\\\$IP\\home\\`whoami`\\dev E:

This is also a workaround, but gives me better performance than the \wsl$ share
NOTE: This solution does not handle "german umlauts" in file names correctly.

@tracker1
Copy link

@tracker1 tracker1 commented Apr 11, 2022

I experienced this, yet again myself this past week... I keep two ~/src directories, one in WSL, another in Windows... mostly depending on what I'm working on... was playing with dev containers (Docker+WSL). Man, it was painfully slow, then the next day realized I was using a directory on my Windows side.

I don't know why this is so much slower than SMB/CIFS or NFS sharing between the two, but really something that should be looked at closer.

@rPraml thanks for suggesting NFS, may give that a try so I can just have a single ~/src and symlink it to my home dir in windows, which I actually use less.

@rPraml
Copy link

@rPraml rPraml commented Apr 11, 2022

@tracker1 FYI if you plan to use git as scm.

Git does not work reliable on an NFS share - I get "permission denied" errors for several git commands.
It seems that some file-io (like file locking) isn't implemented in NFS 3 (didn't try NFS 4, because it is not supported by Windows out of the box)

@melvinwallerjr
Copy link

@melvinwallerjr melvinwallerjr commented Apr 11, 2022

I am experiencing the same file access performance issues. I installed Ubuntu to my Windows 10 machine. File access from Ubuntu to Windows 10 was good. Then changed Ubuntu from WSL1 to WSL2 and file access is now very slow. It takes four times as long to perform the same file operations in WSL2.

Environment: Windows 10 Pro, Version 21H1, build 19043.1620
Linux: Ubuntu 20.04 LTS, WSL version 2

@tracker1
Copy link

@tracker1 tracker1 commented Apr 13, 2022

@rPraml would you suggest just using samba/cifs then? Maybe host in docker container/volume and mound in my host (windows) and wsl (linux)... I also use macos, so thinking of doing this as much for making that environment as similar as possible.

@bhechinger
Copy link

@bhechinger bhechinger commented Apr 14, 2022

@rPraml would you suggest just using samba/cifs then? Maybe host in docker container/volume and mound in my host (windows) and wsl (linux)... I also use macos, so thinking of doing this as much for making that environment as similar as possible.

Before I switched back to Linux full time I had ditched WSL in favor of using multipass. It "feels" a lot like WSL but works way better. It's also available on MacOS and Linux so you have have the same setup everywhere. I highly recommend it.

@rPraml
Copy link

@rPraml rPraml commented Apr 14, 2022

@tracker1 I use a lot of git repositories and I want to use the same source code folder both on windows and on linux.
Genereally I've two options

  • Put the sources somewhere under C:\myfolder and access them with /mnt/c/myfolder in WSL 2
  • Put the sources somewhere inside the WSL container in /home/user/myfolder and access it with \\wsl$\Ubuntu\home\user\myfolder
    both solutions have performance problems, as soon as the files have to go over the WSL file service (the direction does not matter, both is slow)
    So I tried to replace the "\wsl$" file access by NFS - which gives me a 2-3 times better file performance (tested with time git status) - but later I noticed, that many git commands have problems due file locking on NFS. So see my NFS hack some posts above as a Proof Of Concept to test if more performance is possible. Yes it is. But for now, I would not suggest to use that in production.

Why I am doing this? Compiling on WSL is faster. My maven builds are nearly twice as fast on WSL than on windows. It seems that linux is having much better IO performance than windows (try copying a folder with ~20000 small files. This is possible in a fraction of a second in WSL, but takes 10 seconds or more on windows)

@BonusLord
Copy link

@BonusLord BonusLord commented Apr 14, 2022

Putting the src folder on the WSL2 filesystem should be pretty viable for some scenarios at least (specifically, the current performance nuances seem to support the case of web app development fairly well). As long as you do all your building and Git operations from the WSL2 terminal, performance should be pretty solid.

Unfortunately, my main use case is desktop app development in Eclipse, so the src kind of has to live on the widows filesystem (otherwise, compilation / app performance is miserable). Since version control cmds are unusably slow under WSL2 when the repo lives on the Windows filesystem, the only sane options right now (if you want to use a unix-like terminal for VCS ops) are to either use WSL1 or Cygwin.

@tidunguyen
Copy link

@tidunguyen tidunguyen commented Apr 18, 2022

@BonusLord I had the same problem as you a while back whne using Intellij. I switch to the Linux version by installing all my IDE inside wsl. I used mobaxterm to forward the X graphic session back then but switched to WSLg now (as WSLg provide all graphical and sound config out of the box). I can then store all my projects inside WSL while using graphical tools like IDE. VSCode with WSL remote extension is also a very popular choice if your use case allow.

@j0eii
Copy link

@j0eii j0eii commented Apr 18, 2022

I cant tolerate it, so I just test the mutagen alternative fix.

Here is the fix based on mutagen: I wrote the docs here, and tested it, it works great.

https://j0eii.cwh-labs.com/wsl2-extremely-slow-file-read-fix-mutagen/

It really been a long long time for this one. Thanks @kyriakos for the issue fix suggestion, and Microsoft for providing WSL2 docker, and everyone whom discussed this issue fix.

^^^^ to anyone whom still has this issue, you may try this solution, it works well over my last year. It also should work under windows 11.

@tracker1
Copy link

@tracker1 tracker1 commented Apr 18, 2022

Worth noting, if you're using WSL on Windows 11, you can use GUI linux apps from WSL on the desktop pretty easily... so that may be an option as well. I do hope this sees better integration, but since I multi-boot, Win11 really isn't a supported option for me. TBH, mostly running in the linux environment directly.

@nicohouillon
Copy link

@nicohouillon nicohouillon commented Apr 27, 2022

I cant tolerate it, so I just test the mutagen alternative fix.
Here is the fix based on mutagen: I wrote the docs here, and tested it, it works great.
https://j0eii.cwh-labs.com/wsl2-extremely-slow-file-read-fix-mutagen/
It really been a long long time for this one. Thanks @kyriakos for the issue fix suggestion, and Microsoft for providing WSL2 docker, and everyone whom discussed this issue fix.

^^^^ to anyone whom still has this issue, you may try this solution, it works well over my last year. It also should work under windows 11.

but this require Docker-desktop to be running at all time . Not great !

@nicohouillon
Copy link

@nicohouillon nicohouillon commented Apr 27, 2022

this is better than mutagen IMO while waiting for a fix, no need to run docker in the background all the time
https://lifesaver.codes/answer/git-status-is-slow-in-wsl2-4401
BTW, is microsoft working on a fix or ?

@SuperSandro2000
Copy link

@SuperSandro2000 SuperSandro2000 commented Apr 28, 2022

lifesaver.codes/answer/git-status-is-slow-in-wsl2-4401

That is the original link #4401 without the proxy spam site.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests