1. Este error significa que el acceso a archivos en el sistema de archivos host de Windows desde un contenedor de Linux funcionará un poco más lento que el acceso a archivos que ya están en un sistema de archivos de Linux. Acceder a archivos de Windows desde el contenedor de Linux funcionará como acceder a archivos en un recurso compartido de archivos remoto.

2. Docker y Microsoft recomiendan evitar esto almacenando sus archivos de origen en el sistema de archivos de una distribución WSL2 (que puede vincular al contenedor) o creando su imagen de contenedor para incluir todos los archivos necesarios en lugar de almacenar sus archivos en el sistema de archivos de Windows.

3. Si ha hecho clic en "No volver a mostrar", puede acceder a los detalles de este mensaje yendo a Desarrollar con Docker y WSL 2 .

Para obtener más información, Docker para las mejores prácticas de Windows dice:

• Los contenedores de Linux solo reciben eventos de cambio de archivo ("eventos de notificación") si los archivos originales están almacenados en el sistema de archivos de Linux. Por ejemplo, algunos flujos de trabajo de desarrollo web se basan en eventos de notificación para la recarga automática cuando los archivos han cambiado.
• El rendimiento es mucho mayor cuando los archivos se montan en enlace desde el sistema de archivos de Linux, en lugar de hacerlo de forma remota desde el host de Windows. Por lo tanto, evite docker run -v /mnt/c/users:/users (donde /mnt/c está montado desde Windows).
• En su lugar, desde un shell de Linux, use un comando como docker run -v ~/my-project:/sources <my-image> donde el shell de Linux expande ~ a $HOME.

El artículo Comparación de WSL 1 y WSL 2 de Microsoft tiene una sección completa sobre el rendimiento en los sistemas de archivos del sistema operativo , y su párrafo inicial dice:

Recomendamos no trabajar en todos los sistemas operativos con sus archivos, a menos que tenga una razón específica para hacerlo. Para obtener la mayor velocidad de rendimiento, almacene sus archivos en el sistema de archivos WSL si está trabajando en una línea de comandos de Linux (Ubuntu, OpenSUSE, etc.). Si está trabajando en una línea de comandos de Windows (PowerShell, símbolo del sistema), almacene sus archivos en el sistema de archivos de Windows.

Además, el artículo del blog de Docker Docker Desktop: Mejores prácticas de WSL 2 tiene una sección "Impresionante rendimiento de montajes" que dice:

Tanto su propia distribución WSL 2 como docker-desktop se ejecutan en la misma VM de utilidad. Comparten el mismo Kernel, caché VFS, etc. Simplemente se ejecutan en espacios de nombres separados para que tengan la ilusión de ejecutarse de forma totalmente independiente. Docker Desktop aprovecha eso para manejar montajes de enlace desde una distribución WSL 2 sin involucrar ningún sistema remoto de intercambio de archivos. Esto significa que cuando monte sus archivos de proyecto en un contenedor (con docker run -v ~/my-project:/sources <...> ), docker propagará eventos inotify y compartirá el mismo caché que su propia distribución para evitar la lectura el contenido del archivo del disco repetidamente.

Sin embargo, una pequeña advertencia: si monta archivos que viven en el sistema de archivos de Windows (como con docker run -v /mnt/c/Users/Simon/windows-project:/sources <...> ), no obtenga esos beneficios de rendimiento, ya que /mnt/c es en realidad un punto de montaje que expone los archivos de Windows a través de un recurso compartido de archivos de Plan9.

Todos esos consejos son excelentes si desea que su flujo de trabajo de desarrollo principal esté en Linux. Docker quiere que vaya "todo incluido" en los contenedores de Linux. Pero si trabaja principalmente en Windows y solo quiere usar un contenedor de Linux para una tarea especializada, puede hacer clic en "No volver a mostrar". Como dijo Microsoft, "si está trabajando en una línea de comandos de Windows, almacene sus archivos en el sistema de archivos de Windows".

Ejecuto mi carpeta de desarrollo principal en Windows y la vinculo a montarla en un contenedor de Linux que solo se usa para ejecutar pruebas unitarias. Entonces, mi compilación completa se ejecuta en Windows, luego ejecuto todas mis pruebas unitarias en Windows y termino ejecutando todas mis pruebas unitarias también en un contenedor de Linux. Tener el montaje de enlace de Linux en mi carpeta de Windows funciona rápido y excelente para este escenario en el que la llamada de "prueba de dotnet" en Linux solo está cargando y ejecutando las DLL requeridas de mi volumen de Windows.

Esta configuración puede sonar como una herejía para aquellos que creen que los contenedores deben usarse en todas partes, pero me encantan los contenedores para la implementación de aplicaciones. No estoy convencido de que deba ir con todo y hacer todo su desarrollo dentro de un contenedor también. Estoy contento con Windows (y VS 2019) como mi entorno de desarrollo, y luego uso contenedores de Linux para probar e implementar aplicaciones. Por lo tanto, el impacto en el rendimiento del sistema de archivos de Windows/WSL2 es un impacto mínimo para mí.