Docker Desktop 2.3.02 host volume mount performance

Expected behavior

Windows 10 host mounted volumes performance which is comparable with previous versions of Docker Desktop.

Actual behavior

performance of file i/o against Windows 10 host mounted volumes appears to have taken an extreme turn for the worse.

In my case I'm performing a "build" which involves 70k+ files and some tarring and untarring. The results of this build in various environments are as follows:
12 minutes - Straight Windows 10 (git bash)
19 minutes - Docker Desktop 2.1.0.5 against host mounted volume (Windows /c drive)
71 minutes - Docker Desktop 2.3.0.2 against host mounted volume (Windows /c drive)
2 minutes - Docker Desktop 2.1.0.5 against container file system
2 minutes - Docker Desktop 2.3.0.2 against container file system

Information

Please, help us understand the problem. For instance:

• Is it reproducible?
  Yes
• Is the problem new?
  Yes
• Did the problem appear with an update?
  Yes
• A reproducible case if this is a bug, Dockerfiles with reproduction inside is best.
  I've not attemped to simplify this yet. But a large zip/tar file being unzipped and then rezipped would likely show the issue

-->

• Windows Version:
  10
• Docker Desktop Version:
  2.3.0.2
• Are you running inside a virtualized Windows e.g. on a cloud server or on a mac VM:
  No

[Geekimo]

Got the same problem using a php container to run Symfony framework.
Displaying application homepage previously took ~600ms, now it takes about 11s.
Running wsl2 containers with wsl2 update as required.

[mat007]

Thanks for the report, is this with the WSL 2 or the Hyper-V backend?
Could you provide diagnostics (Troubleshoot window from the systray menu)?

[Geekimo]

Hi,
mine is using WSL2, and here is the diagnosis id -> 947B4C0B-BE38-4B2B-89B7-8E9ABD5D4989/20200516103831

I don't have diagnostics handy but will try and pull that together on Monday.

My original numbers were Hyper-V

I've since switched to WSL2 and the numbers when using Windows volume mount are still what I described originally.

Not surprisingly if I use a mount to file system in WSL then the numbers are quite good. Essentially the same as if I had everything directly in the container itself.

[Geekimo]

Disabling WSL2 and going back to the Hyper-V backend made me recover decent performances.

[simonferquel]

Bind mounting files from Windows into wsl2 is very costly indeed. The best practice about bind mounts with the WSL 2 backend is to fully embrace WSL 2 and host your source files in your WSL distro instead of on the Windows file system. In this scenario, bind mounts performance is much better than with the Hyper-V backend.

[bashess]

Same problem here with Hyper-V backend. Since update from 2.2.0.0 build time raised from 12 minutes to 35 minutes.

[simonferquel]

Hi all,

Can you please describe the reason why you could not put your source files inside you wsl 2 distro filesystem ? Doing this bring you:

• Linux-native-like IO performance and features (including kernel caching, inotify support, uid/gid and permissions capabilities)
• Running your build scripts and tools from a real Linux environment instead of a Windows environment.

I know that some IDEs have limitations with working with the \wsl$ file share, and would really like to author IDE-specific workarounds and guidance for having the best development experience as well as running performances.

[Geekimo]

I'm doing PHP, I do not need to build my code every time to test it.

The problem is about the fact that we always worked like this under Windows, then suddenly we have to do it an other way without any clear information or complete documentation.

At this point, I load my code from a volume specified in my docker-compose.yaml. How should I declare it now to use the advantages of WSL2 ?

[simonferquel]

is it a named volume, or a mount from the Windows host ?

If it is a named volume, you can continue like this.
If it is a mount from the windows host, you should:

• move your sources to a wsl2 distro (e.g. from Ubuntu: copy /mnt/c/sources ~/sources)
• use the docker and docker-compose from your wsl2 distro (cd ~/sources && docker-compose up

If you use Visual Studio Code, you can run it in "Remote WSL mode" (just run code . from your wsl distro, and it will run vs code UI connecting to the WSL instance)

Otherwise, other editors can access your WSL 2 files via the network share \\wsl$\<distro name\

[Geekimo]

Second case, mount from Windows.
I'll try later and let you know.

@simonferquel Couldn't agree more that keeping source in WSL 2 and using docker/docker-compose from within that space is a great performance improvement. Even over native Windows.

I did go down that WSL 2 path as indicated by the numbers I posted. However Windows build 2004 is not even generally available yet. I had to go WIndows Insider Preview to use WSL 2 and provide those numbers.

I work in a large enterprise and had to get special permission to even try the Insider Preview and get WSL 2. Even though Windows build 2004 will be generally available on May 28th that doesn't mean developers in large corporations will have access to it. Before they drop it in place for general usage it will go through a wide array of security and compatibility testing internally which could put it another 6 months off.

But it is pretty hard to stomach that without encouraging thousands of developers to ask for Insider Preview permissions and changing up the way everyone works that DD 2.3.02 is ~6 times slower than native Windows and ~3 times slower than DD 2.1.0.5.

[simonferquel]

@jtoe using the Hyper-V backend, you should see performance improvements compared to DD 2.1.0.5. It is only the WSL 2 backend that suffers this performance issue when mounting windows files.

This is because our hyper-v backend comes with GRPC Fuse, which we cannot enable on WSL 2 backend, due to dependencies on some Linux Kernel patches.

In term of performance, you should see things in this order:

• 2.3.0.2 WSL 2 backend mounting files from Linux file system
• 2.3.0.2 Hyper-V backend mounting files from Windows
• 2.1.0.5 Hyper-V backend mounting files from Windows
• 2.3.0.2 WSL 2 backend mounting files from Windows