Corrige el listado lento de directorios S3 al montar con NetDrive
Diagnostica y soluciona el listado lento de archivos al montar buckets grandes de Amazon S3 con NetDrive. Cubre límites de la API S3, caché de NetDrive y estructura del bucket.
Un equipo de backend monta un bucket de Amazon S3 como una letra de unidad de Windows a través de NetDrive para su pipeline de fixtures de CI. Funciona sin problemas durante meses — hasta que una refactorización agrega 40.000 nuevos objetos de fixtures de prueba bajo un único prefijo de S3. La build de la mañana siguiente se cuelga 90 segundos durante la preparación de las pruebas, esperando a que el directorio de fixtures se rellene en el Explorador. NetDrive no está bloqueado; está haciendo 40 llamadas secuenciales a la API de S3 solo para enumerar ese directorio.
Monta buckets de S3 como una unidad nativa de Windows o macOS
NetDrive hace que Google Drive, OneDrive, S3, SFTP, WebDAV y más aparezcan como unidades nativas en Windows y macOS — sin sincronizar, sin descargas completas.
- Los buckets de S3 aparecen como D:, E:, o cualquier letra de unidad en Windows
- Listados de directorio en caché para un acceso repetido más rápido tras el primer montaje
- Fuerza la actualización de carpetas específicas cuando cambian los objetos de origen
Prueba gratuita. Planes de por vida y de suscripción disponibles.
Por qué el listado de S3 es más lento que un sistema de archivos local
S3 es almacenamiento de objetos, no un sistema de archivos jerárquico. Lo que parece una carpeta llamada fixtures/integration/ es un prefijo de clave compartido — miles de claves de objeto que resultan comenzar con esa cadena. No existen directorios reales. NetDrive (y cualquier otra herramienta de montaje de S3, incluyendo rclone y ExpanDrive) simula directorios llamando a la API ListObjectsV2 de S3.
El problema: una llamada a ListObjectsV2 devuelve como máximo 1.000 objetos. Un prefijo con 40.000 claves necesita 40 llamadas secuenciales a la API para enumerarse por completo. A 50 ms por ida y vuelta al endpoint de S3 (razonable dentro de la misma región de AWS), eso son 2 segundos de sobrecarga pura de API antes de que se muestre el primer nombre de archivo en el Explorador. A través de un proxy corporativo o hacia una región distinta, esas 40 llamadas pueden extenderse a 30–90 segundos.
Esto no es un error de NetDrive. Es el contrato de la API de S3 — el mismo comportamiento afecta a aws s3 ls, al modo de montaje de rclone y a cualquier otra herramienta que liste prefijos grandes de S3. La solución tiene dos frentes: cómo NetDrive cachea los listados de directorio y cómo estructuras tu bucket.
Cómo la caché de directorios de NetDrive reduce la sobrecarga repetida
Después del primer listado de un prefijo grande, NetDrive cachea el árbol de directorios localmente. La próxima vez que cualquier proceso navegue a D:\fixtures\integration\, NetDrive devuelve el listado en caché sin una sola llamada a la API de S3. Esta caché es persistente entre sesiones: tras un arranque en frío, la caché sigue estando activa desde el montaje anterior, así que el listado de la segunda ejecución es instantáneo incluso si reiniciaste el servidor de build durante la noche.
El tamaño de almacenamiento de la caché es configurable hasta 1 TB (introducido en NetDrive 3.16.589). Para un bucket con cientos de miles de objetos distribuidos en docenas de prefijos, asignar más espacio de caché mantiene más del árbol activo entre ejecuciones de CI. Ajusta esto en la configuración de la unidad dentro de Drive Manager.
El costo es la desactualización. Si un colega o un pipeline de origen sube nuevos objetos directamente a S3 — a través de la consola de AWS, una herramienta distinta u otra máquina — la vista en caché de NetDrive no reflejará esos cambios hasta que la caché expire o actives una actualización. Para actualizar una carpeta específica: clic derecho en el Explorador de Windows → Refresh. NetDrive vuelve a emitir la llamada ListObjectsV2 para ese prefijo, actualiza la caché y devuelve el listado actual.
Cambios en la estructura del bucket que reducen la sobrecarga de listado
Estas soluciones requieren cambios en cómo organizas tu bucket de S3, pero benefician a toda herramienta que lo lea — no solo a NetDrive.
Aplana jerarquías profundas de prefijos. Cada nivel de anidamiento que navegas dispara su propia llamada de listado. Una ruta como fixtures/integration/service-a/env-staging/2026/05/ tiene seis niveles — hasta seis llamadas secuenciales a la API antes de llegar a los objetos. Aplánala: fixtures/integration/service-a-staging-2026-05/ almacena los mismos datos con una única llamada de listado para llegar a la hoja.
Particiona los prefijos de alta cardinalidad por tiempo o categoría. Si un único prefijo logs/ contiene 80.000 objetos que abarcan dos años de salida diaria, divídelo en logs/2025/ y logs/2026/. Cuando NetDrive lista logs/, ve dos subprefijos en una única llamada a la API. Navegar a logs/2026/ requiere entonces solo una llamada más para ese año.
Separa los datos activos de los fríos. Mantén los objetos leídos activamente en un prefijo acotado — fixtures/active/ — y archiva los más antiguos en fixtures/archive/. Los pipelines de CI que montan todo el bucket pero solo leen fixtures/active/ listan rápido; el archivo frío queda fuera de caché y fuera de la ruta crítica.
Define un Root path en la unidad. En la configuración de conexión S3 de NetDrive, el campo Root path te permite montar un prefijo específico como raíz de la unidad. Configúralo como fixtures/active y NetDrive tratará ese prefijo como D:\. El resto del bucket nunca se lista durante la sesión de montaje — solo la ruta que tu herramienta realmente necesita.
Verifica la región del endpoint. Abre la conexión S3 en Drive Manager y confirma que la región coincide con la región de origen de tu bucket. Una solicitud entre regiones añade 50–200 ms por llamada a la API. A lo largo de 40 llamadas de listado paginadas, son 2–8 segundos evitables de latencia de red en cada apertura de directorio en frío.
Resumen
El listado lento de directorios S3 es casi siempre un problema de estructura del bucket, no de configuración de NetDrive. El límite de 1.000 objetos por llamada de la API de S3 es fijo; lo que controlas es cuántas llamadas se necesitan para llegar a los objetos que tus herramientas necesitan. Aplana jerarquías profundas, particiona los prefijos de alta cardinalidad, define un root path para acotar el montaje, y deja que la caché de directorios mantenga los listados repetidos instantáneos.
Para equipos que enfrentan errores de permisos en S3 en lugar de problemas de rendimiento, consulta Fix S3 Access Denied Error with NetDrive. Si tu pipeline de CI usa Wasabi en lugar de AWS S3, el mismo comportamiento de listado aplica — consulta Mount Wasabi on Windows with NetDrive.
— Jay, NetDrive