Rendimiento del sistema de archivos de WSL: por qué el acceso entre sistemas operativos ralentiza tu código

By Mirko Peters · 2026-10-27

Descubre por qué el acceso a archivos entre sistemas operativos ralentiza WSL. Mejores prácticas para almacenar en el sistema de archivos nativo de Linux y acelerar tus flujos de trabajo de desarrollo.

Automatically translated with AI from the original post. Read the English original

Descubre por qué mezclar los sistemas de archivos de Windows y Linux en el Subsistema de Windows para Linux (WSL) crea cuellos de botella de rendimiento muy importantes. Aprende las reglas fundamentales para mantener tus directorios de proyecto en el lado correcto de la frontera del sistema operativo y acelerar de forma notable las tareas de compilación con mucho uso de disco, las instalaciones de paquetes y las operaciones de git.

Puntos clave

• Almacenar archivos de proyectos de Linux en unidades de Windows (mediante /mnt/c/) provoca una degradación severa del rendimiento debido a los costes de traducción al cruzar la frontera.
• Los árboles de archivos masivos, como los directorios node_modules, son los más afectados al cruzar la frontera del sistema operativo durante las compilaciones y actualizaciones.
• La recomendación oficial de Microsoft es mantener tus archivos en el mismo sistema operativo que las herramientas que usas para editarlos y compilarlos.
• VS Code ofrece la extensión Remote WSL, que te permite editar archivos alojados en Linux con una interfaz de Windows, sin penalizaciones de rendimiento.
• Las reglas de distinción entre mayúsculas y minúsculas difieren drásticamente entre los sistemas de archivos de Windows y Linux, por lo que una ubicación adecuada de los directorios es esencial para evitar errores inesperados.

Entender la división entre los sistemas de archivos de Windows y Linux

Uno de los errores más comunes que cometen los desarrolladores al adoptar el Subsistema de Windows para Linux es una mala ubicación de los archivos. Windows y Linux gestionan su almacenamiento subyacente mediante paradigmas arquitectónicos completamente distintos. Cuando usas WSL 2, estás utilizando un kernel de Linux auténtico que se ejecuta dentro de una máquina virtual ligera. Esto significa que tu distribución de Linux mantiene su propio sistema de archivos nativo y aislado, que funciona según los estándares POSIX.

Por el contrario, tu entorno estándar de Windows depende de NTFS y utiliza letras de unidad, como tu unidad C:. Para salvar la distancia, WSL monta automáticamente tus unidades de Windows dentro del entorno de Linux, en el directorio /mnt/; por ejemplo, tu unidad C aparece como /mnt/c. Aunque esto permite leer y escribir todos los archivos de tu equipo host desde la terminal de Linux, introduce un coste oculto y muy elevado de rendimiento conocido como la ruta de traducción entre sistemas.

Por qué el acceso a archivos entre sistemas se arrastra

Cada vez que una herramienta de Linux lee o escribe un archivo ubicado en el lado de Windows del sistema, la solicitud debe atravesar la frontera entre la máquina virtual ligera y el host de Windows. Para un único archivo de texto o un script pequeño, esta sobrecarga de traducción es imperceptible. Sin embargo, los flujos de trabajo de desarrollo de software actuales rara vez involucran un solo archivo.

Piensa en lo que ocurre cuando ejecutas un comando como npm install o git clone en un directorio de proyecto ubicado en /mnt/c/mi-proyecto. Estas operaciones generan miles de solicitudes de creación y modificación de archivos pequeños en rápida sucesión. Cada uno de esos archivos diminutos paga el coste de cruzar la frontera. El efecto acumulado es que operaciones que deberían tardar segundos pueden prolongarse durante minutos, lo que lleva a muchos desarrolladores a creer erróneamente que WSL en sí es inherentemente lento, cuando el verdadero culpable es simplemente una mala ubicación del directorio.

Distinción entre mayúsculas y minúsculas y conflictos de permisos

El rendimiento no es la única víctima al cruzar la frontera entre sistemas operativos. Las reglas del sistema de archivos subyacente también chocan de formas que rompen las aplicaciones. La raíz nativa del sistema de archivos de Linux distingue estrictamente entre mayúsculas y minúsculas. Dos archivos llamados Script.js y script.js se tratan como entidades completamente distintas. Windows NTFS, por defecto, no distingue entre mayúsculas y minúsculas.

Además, las utilidades de línea de comandos de Linux dependen en gran medida de las marcas de propiedad y permisos gestionadas por utilidades como chmod y chown. Los sistemas de archivos de Windows no asignan estos permisos de forma nativa de la manera que esperan las herramientas de Linux. Cuando ejecutas código a través de la frontera, los enlaces simbólicos pueden no resolverse correctamente, y los scripts de compilación pueden devolver errores poco claros porque no pueden aplicar los permisos de archivo que requiere el entorno de ejecución.

Buenas prácticas para flujos de trabajo rápidos en WSL

Para evitar estas trampas de rendimiento y mantener una experiencia de desarrollo fluida, debes seguir dos hábitos fundamentales. Primero, mantén siempre tus proyectos Linux dentro del sistema de archivos nativo de Linux (en algún lugar de tu directorio personal, como ~/projects/), y mantén tus proyectos exclusivamente de Windows en el lado de Windows.

Segundo, aprovecha el potencial de las herramientas modernas para conectar tu interfaz de usuario sin sacrificar la velocidad de ejecución. No necesitas abandonar tus editores de Windows favoritos. Mediante la extensión Remote - WSL para Visual Studio Code, puedes abrir un proyecto almacenado íntegramente en el sistema de archivos nativo de Linux mientras disfrutas de una interfaz gráfica de Windows, ágil y familiar. Tu editor se ejecuta en Windows, pero la ejecución del código, las pruebas y la gestión de paquetes se realizan a máxima velocidad dentro del entorno Linux.

Conclusión y próximos pasos

Dominar los límites del sistema de archivos es el paso más importante para convertir WSL de un experimento frustrante en tu herramienta de trabajo diaria. Al mantener tus herramientas y archivos alineados en el lado correcto de la división del sistema operativo, eliminas la latencia y evitas errores de permisos difíciles de entender.

Para una visión más amplia de cómo esta función se integra en los flujos de trabajo modernos de desarrollo y en la nube, escucha el episodio completo del podcast M365 FM. ¡Sumérgete en la conversación completa para explorar atajos de instalación, comparativas de versiones y cómo WSL conecta las máquinas locales con la infraestructura de Azure en la nube!

Preguntas frecuentes

¿Dónde debo almacenar los archivos de mis proyectos al usar WSL?

Debes almacenar los archivos de tus proyectos dentro del sistema de archivos nativo de Linux (por ejemplo, en tu directorio personal, como ~/mi-proyecto), en lugar de en las unidades de Windows montadas (como /mnt/c/), para garantizar la máxima velocidad de lectura y escritura.

¿Por qué es lento ejecutar npm install en mi unidad de Windows desde WSL?

Los gestores de paquetes como npm o pip generan miles de archivos pequeños durante la instalación. Cuando estos archivos se escriben a través de la frontera del sistema operativo en una unidad NTFS de Windows, cada archivo individual incurre en una sobrecarga de traducción, lo que provoca cuellos de botella de rendimiento importantes.

¿Puedo usar Visual Studio Code para editar archivos almacenados en el sistema de archivos de Linux?

Sí. Al instalar la extensión Remote - WSL para Visual Studio Code, puedes abrir, editar y depurar de forma nativa archivos ubicados dentro de tu distribución Linux de WSL, usando la interfaz del editor estándar de Windows.

¿Cuál es la diferencia entre la forma en que Windows y Linux gestionan los nombres de archivo?

Los sistemas de archivos de Linux distinguen estrictamente entre mayúsculas y minúsculas (tratan File.txt y file.txt como archivos diferentes), mientras que Windows NTFS no distingue entre mayúsculas y minúsculas por defecto. Ejecutar herramientas de Linux en directorios alojados en Windows suele provocar fallos de compilación debido a estas diferencias de comportamiento subyacentes.