-
Notifications
You must be signed in to change notification settings - Fork 834
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
Comments
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! |
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. |
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. |
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. |
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" :) ). |
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 ( |
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 A more accessible approach might be to emit "5% 10% 20% ... 100% ... complete", or similar. |
Ok, so... can we reopen either of those issues for tracking at least UX improvements? |
+1 for status indicator. (I actually wanted to post a feature request, when I found this.)
What an optimistic estimate... Most blogposts I've seen states +30min up to 2-3 hours. Personally 1 hour and counting. 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. |
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. |
Can coat-tail off #6028 perhaps. |
Environment
Steps to reproduce
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.)
The text was updated successfully, but these errors were encountered: