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

Very slow conversion process due to Windows Defender #5403

Closed
RReverser opened this issue Jun 13, 2020 · 13 comments
Closed

Very slow conversion process due to Windows Defender #5403

RReverser opened this issue Jun 13, 2020 · 13 comments

Comments

@RReverser
Copy link

Environment

Windows build number: 10.0.19041.0
Your Distribution version: Ubuntu 18.04
Whether the issue is on WSL 2 and/or WSL 1: (in between)

Steps to reproduce

  • (you need to have a distribution on WSL1)
  • Install WSL2.
  • Upgrade the existing distribution with wsl --set-version 2 DistributionName.

Expected behavior

Conversion takes couple of minutes, as per the console message.

Actual behavior

Conversion takes over 40 minutes and counting.

Additional context

Initially I've been tweeting about this issue with @bitcrazed following along, and noticed it on work computer; around 40 minutes in, I've decided to try on home computer and reproduced it as well.

Task manager showed bsdtar, Windows Defender and few other processes (on work computer also including a custom AV solution) in the top, so I suspected that AV might be a culprit of poor I/O performance as if often is.

Indeed, even on home computer with just Windows Defender with default settings, Task Manager has been showing bsdtar using disk at the speed of ~1.8 MB/s. As soon as I've disabled Windows Defender's realtime protection, the speed went up to ~130 MB/s average, with bursts reaching as much as ~180 MB/s - that is, at least 70x faster.

As soon as I've done that, the home computer finished compression within approximately 2 minutes, while the work one was still trying to convert the image. Due to corporate policy, we can't disable AV protection, and so I never managed to wait for the conversion to finish and had to start with a clean slate.

As mentioned above, I know that it's fairly common for AV to cause I/O performance problems, but perhaps there is at least some way to make Windows Defender and the converter to play nice together.

I imagine - in fact, I know - that I'm not the only one who got stuck in the same situation, e.g. see this comment by @mureni - #4102 (comment) - from a year ago which describes pretty much exactly same symptoms. (I found it while searching for similar issues.)

@therealkenc
Copy link
Collaborator

/dupe #5310 -> #4197 with a side of #4669.

@ghost
Copy link

ghost commented Jun 15, 2020

Hi! We've identified this issue as a duplicate of another one that already exists in this repository. This specific instance is being closed in favor of tracking the concern over on the referenced thread.

Thanks for your report!

@ghost ghost added the duplicate label Jun 15, 2020
@RReverser
Copy link
Author

RReverser commented Jun 15, 2020

I'm surprised #5310 (which does look like a dupe of this, but I didn't find it because it was closed) was marked as dupe of #4197.

#4197 is about filesystem performance of host mounts in WSL2, which is not very related to upgrades, and it (or, at least, the latest public update - #4197 (comment)) doesn't mention Defender either, which was the cause of performance issue here.

I believe these two issues should be tracked separately, since disabling AV fixes this particular issue altogether.

@therealkenc
Copy link
Collaborator

Yes #873 and #1932 too. If you can't disable defender there isn't much working around those, short of going all-in a --set-default-version 2 install from the store.

@RReverser
Copy link
Author

Would it be a possible resolution to at least automatically add exclusion to Defender for the conversion process?

It won't help with strict environments, but at least others won't have to go via same process searching for reasons why conversion is seemingly stuck and how to work around it.

@therealkenc
Copy link
Collaborator

therealkenc commented Jun 16, 2020

Would it be a possible resolution to at least automatically add exclusion to Defender for the conversion process?

That's a pretty reasonable question, that has an unfortunate answer. Disabling Defender for any reason is anathema in influential circles. We could, say, bend your OP into feature request "Automatically disable Defender on hidden WSL1 distro path during upgrade", but I can say with a pretty high degree of confidence it would never see light. There is also the problem that disabling Defender (even in unrestricted environments) is a privileged operation while the WSL1->2 conversion process is not. [The likelihood of a UAC prompt for conversion is... basically nil.]

One could make a pretty good case that WSL1->2 upgrade can take a long time should be documented better. Suggestions for improvements over here. But for the aforementioned reason, it is doubtful that one could get "disable defender" on the books as documented standard operating procedure, contrast common lore you find on the web.

@RReverser
Copy link
Author

Fair enough, thanks for the detailed explanation. Seems like a dead end, with neither possibility of fix nor even documentation of work-around in sight...

I guess at least changing the message so that it wouldn't say "should take a few minutes" would be a good low bar (with possible further improvements in form of e.g. adding progress bar and/or linking to the specific Github issue so that people can find the workaround more easily, without explicitly saying "disable Defender" :) ).

@therealkenc
Copy link
Collaborator

I have a possible feature request suggestion I almost added to #5344 (that one got closed by submitter so I let it go). The conversion process deserves some kind of progress indicator, even if it were some primitive ascii dot dot dot (...) every 100 files converted or whatever. It is generally frowned upon in UX circles for a process to sit in silence with no feedback for 40 minutes. I don't think anyone can argue with that. For consideration by anyone motivated enough to submit it.....

@bitcrazed
Copy link
Contributor

Certainly won't argue with that progress indicator would be great, but do consider accessibility: Text-block progress bars, dot indicators, spinning -|/ cursors, etc. tend to play havoc with accessibility on the command-line.

Close your eyes and imagine you're a blind command-line user (there are many!). You type wsl --set-version Ubuntu 2 and your screen reader reads out "dot" "dot" "dot" ... not v. useful.

A more accessible approach might be to emit "5% 10% 20% ... 100% ... complete", or similar.

@RReverser
Copy link
Author

Ok, so... can we reopen either of those issues for tracking at least UX improvements?

@th0ger
Copy link

th0ger commented Oct 1, 2020

+1 for status indicator. (I actually wanted to post a feature request, when I found this.)

Conversion in progress, this may take a few minutes...

What an optimistic estimate... Most blogposts I've seen states +30min up to 2-3 hours. Personally 1 hour and counting.
Yes, my McAfee/Windows defender (which my sysadm controls) is probably derating the performance by several orders of magnitude. So be it, what can we do...

Personally I would prefer to be a bit pragmatic. Ugly "............." or changing the text to "a few minutes or hours depending on your system..." would be WAY better than having to dig reddit and github for relief.

@bitcrazed
Copy link
Contributor

All - rather than piling onto a closed issue that's unlikely to get much attention from the dev team ... because it's a closed issue ... please open a new issue to request/discuss a conversion progress indicator.

Thanks.

@therealkenc
Copy link
Collaborator

Can coat-tail off #6028 perhaps.

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

4 participants