Waiting long for something happen

[martijnvwezel]

A brief description
There are some problems with loading things like git status. It takes to long sometime more then a minute. When my virtual machine does this in milliseconds for the same project. It is also with ssh to other machines, sometimes ssh user@server1156 as example will take 5 a 6 seconds before connection which putty or virtualbox-ubuntu does this imedatelly (server is on the same switch).

Expected results
waiting long for something happen

Windows build number
Microsoft Windows [Version 10.0.14393]

Repro Steps
start bash
$ ssh [user@server1156]

or

go to project git directory
$ git status

output
strace git status

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f5793940a10) = 13611
close(6) = 0
read(5, "", 1) = 0
close(5) = 0
close(4) = 0
read(3,

The last point he is waiting...

[therealkenc]

Git is using some pattern WSL doesn't like from a performance standpoint; there are some comments in #981. Similarly with rsync #1076. I am not sure if the issues are connected though it seems likely.

[aseering]

I forget, what's the default value of git config core.fscache on Ubuntu? Setting it to true is a common performance recommendation on Windows. I wonder if it would help WSL as well. If so, that might shed some light on the source of the performance slowdown. (And be a viable/convenient workaround.)

[misenesi]

You might be hitting an performance issue we are actively investigating with NTFS. Git was written using certain operations that are very fast on Linux but slow on Windows.

[therealkenc]

@aseering Looks like 'core.fscache' option is only respected on Git for Windows. But I think you might have shed a bright light. rsync per #1076 is going to crap all over lstat() too. Weird though, I have never (knowingly) set that config variable on Windows, yet git status is tolerable with large trees.

This link has some pertinent info also. In particular git config core.ignoreStat might be a useful workaround for WSL.

[bootstraponline]

The agnoster theme on both zsh and bash is incredibly slow. Pressing return inside a sizable git repo will trigger a large delay. Spamming return will consume 100% CPU. Most of the delay is attributed to running git commands:

• git rev-parse --git-dir
• git rev-parse --is-inside-work-tree
• git symbolic-ref HEAD
• git rev-parse --short HEAD

Commenting out the git commands helps however the terminal is still quite slow (multi-second delay) when pressing return.

[nesl247]

Why was this closed?

[bootstraponline]

It'd be nice to have a link to some ticket that's tracking the performance issues? If there's not already a ticket, then this should remain open.

[sunilmut]

@bootstraponline - Agreed. I couldn't find one in the user voice page. It might be worthwhile to get one logged there so that people can up vote.

[bootstraponline]

Filesystem is slow is probably the closest existing user voice ticket.

[sunilmut]

@bootstraponline - Thanks. Yes, that's the right one. I was searching with the keyword "perf" :).

[martijnvwezel]

@nesl247 indead I reopend it again ;)

[adeeb1]

I know that some of the performance issues are outside the realm of WSL, but any updates on improving performance? Slow performance, especially for Git and Ruby, really hurts my productivity.

[mo18]

I've noticed the same issue, but I also noticed that the issue is much worse when the directory I cloned the project to was in the windows filesystem. I double checked and for some reason, the cloned project on the windows directory is 369G where the same cloned project is 741M on the linux filesystem. In the following output, "projects" is a symlink to /mnt/c/Users/me/projects.

$ pwd
/home/me

$ ls -l projects
lrwxrwxrwx 1 me me 29 Jul 20 14:48 projects -> /mnt/c/Users/me/projects

$ du -sh projects/mygitproject
369G    projects/mygitproject

$ du -sh mygitproject
741M    mygitproject

[sunilmut]

@mo18 - Do you know what is taking up that much room on the Windows directory? Maybe du is not correctly reporting the size on Windows dirs. Can you double check from explorer or cmd?

[mo18]

@sunilmut - In Windows explorer, the mygitproject directory reports 731 MB.

[sunilmut]

So, it looks like du in DrvFS (/mnt/c etc) in some cases could report false values. Adding @SvenGroot

[SvenGroot]

What build was the "du" output from? There was a bug with block counts reported in both LxFs and DrvFs that leads to "du" giving wildly inaccurate numbers that is fixed in current insider builds, but would be broken in the Creator's Update.

[mo18]

@SvenGroot - I'm on 1703

[therealkenc]

Dupe #981.