WSL 2 está acelerando el acceso al sistema de archivos de Windows

Artículo original ↗ Discusión en Hacker News ↗

Benchmarks y notas técnicas

  • Un usuario compartió una compilación de Hugo en Ryzen 7 + SSD: ~50s en el VHD ext4 interno de WSL frente a ~75s en archivos de Windows vía virtiofs, con ~10s extra por Defender. Aun así, lo consideró una gran mejora frente al anterior DrvFs basado en 9P y un resultado “bueno” para el acceso entre sistemas operativos.
  • Aclaración: “drvfs” es el tipo de montaje; puede usar 9P (antiguo, lento) o virtiofs (nuevo). El benchmark comparó el sistema de archivos interno de WSL frente al acceso por virtiofs a archivos de Windows, no 9P.
  • Algunos informan de un arranque de WSL notablemente más rápido tras actualizar.

Por qué importa el rendimiento del sistema de archivos

  • Hay un consenso fuerte en que el acceso de WSL2 a /mnt/c (unidades de Windows) es o era dolorosamente lento, especialmente para muchos archivos pequeños (por ejemplo, node_modules, requires de Ruby, servidor de desarrollo de Next.js, operaciones de git).
  • Varios señalan que borrar árboles grandes de node_modules desde WSL en Windows puede tardar minutos frente a segundos en Windows nativo.
  • Las explicaciones varían: algunos culpan al propio NTFS; otros dicen que NTFS está bien y que el coste real son los drivers de filtro del sistema de archivos de Windows (Defender, AV, copias de seguridad, sincronización en la nube).

Virtiofs vs 9P y limitaciones

  • 9P sobre virtio se usó porque ya existía en la virtualización de Linux y es simple, pero tiene una lentitud “parecida a NFS”.
  • Se espera que virtiofs cierre parte de la brecha, pero solo afecta al acceso desde WSL a archivos de Windows. El trabajo hecho dentro del propio VHD ext4 de WSL sigue siendo lo más rápido.
  • Algunos enfatizan que incluso con virtiofs, sigues sufriendo la sobrecarga del lado de Windows (filtros, Defender).

Flujos de trabajo de desarrollo y alternativas

  • Consejo habitual: mantener los proyectos de desarrollo en el sistema de archivos ext4 de WSL; copiar hacia/desde /mnt/c según sea necesario.
  • Otros montan volúmenes ext4 separados en WSL y acceden a ellos desde Windows, lo cual puede ser más rápido que la vía inversa.
  • Algunos usan WSL1 para tareas ligeras (por ejemplo, SSH) porque no tiene sobrecarga de VM, pero WSL2 es necesario para Docker/contenedores.

Elección de sistema operativo, gaming y LLMs

  • Varios informan haber abandonado Windows por macOS o Linux principalmente debido a la lentitud del sistema de archivos de WSL/Windows, junto con el fastidio por la integración de Microsoft con la nube y la publicidad.
  • Contrapuntos: otros ven Windows + WSL como un entorno de desarrollo muy bueno, especialmente combinado con la necesidad de jugar y con la amplia presencia de herramientas exclusivas de Windows (Adobe, Office/VBA, VPN, FPGA y herramientas de desarrollo de juegos).
  • Debate sobre el gaming: algunos dicen que Windows está claramente por delante (drivers, anti-cheat), mientras que otros afirman que Linux moderno + Proton a menudo iguala o supera el rendimiento de Windows, y que el anti-cheat es el principal obstáculo.
  • Varios comentarios dicen que los LLMs (Claude, ChatGPT) han reducido drásticamente la fricción de pasarse a Linux, ayudando con la elección de distribución, la configuración y los scripts.

Contexto empresarial y estratégico

  • Muchos usan WSL porque la política corporativa prohíbe Linux en hardware físico pero permite Windows.
  • Algunos ven WSL como “la única forma sensata” de acercarse a Linux en esos entornos.
  • Unos pocos sostienen que Microsoft debería haber arreglado el rendimiento del sistema de archivos de Windows y la parte NT en vez de pivotar de la traducción de syscalls de WSL1 a la VM de WSL2; otros creen que el enfoque de VM era necesario para soportar Docker y la semántica completa de Linux.