Modal acelera bun install 12 veces en sus sandboxes de VM al sustituir virtio-fs por un disco de bloques
Modal lanzó sandboxes de VM y les conectó su sistema de archivos de carga perezosa, ImageFS, mediante virtio-fs. El arranque en frío siguió siendo rápido, pero el trabajo real se resintió: 100 000 llamadas a chown tardaron 9,87 s frente a 1,58 s en el host, y bun install se volvió tres veces más lento. La causa: cada operación de metadatos cruzaba la frontera de la VM hacia el host. La solución: dar al invitado su propia ext4 sobre un dispositivo de bloques.
Procesado por IA desde Modal Blog; editado por Hamidun News
Si construyes sandboxes para agentes, sabes que un arranque rápido no implica un trabajo rápido. El agente instala dependencias, ejecuta grep sobre un repositorio y cambia permisos de miles de archivos. Todo ello depende del sistema de archivos. Los ingenieros de Modal contaron cómo se quemaron con esto al lanzar VM Sandboxes y qué hicieron al respecto.
Arranca rápido, trabaja despacio
Modal tiene desde hace tiempo ImageFS, un sistema de archivos distribuido con carga perezosa para contenedores. Solo descarga de antemano el índice de metadatos y obtiene el contenido de los archivos bajo demanda desde una caché multinivel: memoria, CDN regionales y almacenamiento global. Por eso los contenedores arrancan en menos de un segundo. Para la escritura se usa OverlayFS por encima.
Con las máquinas virtuales la lógica es la misma: la VM tiene su propio kernel invitado y no tiene acceso directo a ImageFS en el host. El puente estándar es virtio-fs, donde el demonio virtiofsd en el host aplica las peticiones del invitado a un directorio compartido. Lo apuntaron a ImageFS y el arranque siguió igual.
Pero en el trabajo real todo se vino abajo. Un chown recursivo que antes tardaba cuatro segundos pasó a tardar más de un minuto. bun install y pnpm install se volvieron aproximadamente tres veces más lentos, y ripgrep fue el más afectado. En un microbenchmark de 100 000 llamadas, chown tardó 9,87 s frente a 2,31 s bajo gVisor y 1,58 s en ImageFS puro.
Por qué un solo chown se convierte en tres viajes
La traza mostró lo esencial. Un solo chown en el kernel invitado se descompone en tres peticiones al host: getxattr para comprobar capabilities, getattr para los bits setuid y setattr para el cambio de propietario en sí. El demonio realiza seis llamadas al sistema y cada una llega a ImageFS. En total, unos 99 µs por operación, a pesar de que virtiofsd ya estaba configurado para el máximo almacenamiento en caché.
La raíz del problema es arquitectónica. virtio-fs es un sistema de archivos compartido: para los metadatos siempre hay que acudir a la autoridad al otro lado de la frontera de la VM. Y eso que el host no necesita en absoluto el contenido del sistema de archivos raíz de la máquina virtual.
Hablar en bloques
Los ingenieros propusieron mantener el sistema de archivos íntegramente dentro del invitado y dar al host solo un dispositivo de bloques mediante virtio-blk. El disco no sabe qué es un archivo: almacena y entrega fragmentos de datos. La ext4 del invitado comprueba por sí misma los permisos, limpia bits y escribe el cambio en el journal. Al host todo llega más tarde, por lotes, cada pocos segundos. Un chown cuesta unos 2,1 µs en lugar de 99.
La dificultad es que mkfs.ext4 exige que toda la imagen esté presente, lo que acaba con la carga perezosa. Por eso el equipo escribe por su cuenta los registros de inodos de ext4 a partir de los metadatos de la imagen y deja el resto disperso (sparse).
El demonio ImageFS-blk convierte las peticiones de bloques en lecturas de rangos de archivos desde ImageFS, y guarda los bloques escritos en un archivo sparse marcándolos en un mapa de bits. Es el equivalente a OverlayFS, pero a nivel de bloques. De paso desaparece un viejo problema: la copia en escritura opera con un solo bloque y no con todo el archivo.
En el peor caso, OverlayFS copiaba gigabytes por unos pocos bytes.
Resultados y la trampa
Las cifras son estas (virtio-fs, ImageFS, ImageFS-blk):
- bun install: 12,5 s, 3,1 s, 1,07 s;
- ripgrep sobre el repositorio de Linux con caché caliente: 6,03 s, 3,77 s, 0,18 s;
- SQLite speedtest1: 543 s, 290 s, 43 s;
- pgbench solo lectura: 98 mil, 137 mil, 230 mil TPS;
- pgbench lectura y escritura: 8,3 mil, 11,9 mil, 18,8 mil TPS.
ImageFS-blk superó incluso al ImageFS original: los metadatos ya no pasan por FUSE. Se mantuvo el arranque en frío en menos de un segundo.
El enfoque tiene un coste. El host ya no ve los archivos dentro de la VM: solo conoce bloques, y los snapshots se calculan a partir del conjunto de bloques modificados. Además, con caché fría, ripgrep sobre el repositorio tarda 8,53 s en ImageFS-blk frente a 4,47 s en el ImageFS normal. Ahí el esquema de bloques pierde. Todas las cifras las obtuvo la propia Modal en su hardware; no hay verificación independiente.
Qué hacer con esto
Si construyes microVM para agentes o CI, no aceptes virtio-fs como sistema de archivos raíz por defecto. Para una sandbox individual en la que el host no lee los archivos del invitado, un sistema de archivos compartido es un impuesto innecesario en cada operación de metadatos. Prueba no solo el arranque en frío, sino también tu escenario real: instalación de paquetes, búsqueda en el código, chown y base de datos. Justo ahí aparece la diferencia de 10 veces.
- 12 nov 2026NVIDIA Vera duplica la velocidad de Modal Sandboxes: hasta 4.281 tareas por minuto con 150 contenedores
- 12 nov 2026Snorkel ejecuta millones de simulaciones de agentes al mes y ahorra un 20 % en sandboxes
- 12 nov 2026Legora ejecuta 2000 pruebas paralelas de su agente jurídico en sandboxes de Modal
- 13 oct 2026Bloom Security halla una vulnerabilidad en la publicación de paquetes y los agentes de IA multiplican el riesgo
Preguntas frecuentes sobre la noticia
¿Qué se sabe sobre Arranca rápido, trabaja despacio?
Modal tiene desde hace tiempo ImageFS, un sistema de archivos distribuido con carga perezosa para contenedores. Solo descarga de antemano el índice de metadatos y obtiene el contenido de los archivos bajo demanda desde una caché multinivel: memoria, CDN regionales y almacenamiento global. Por eso los contenedores arrancan en menos de un segundo. Para la escritura se usa OverlayFS por encima.
¿Qué se sabe sobre Por qué un solo chown se convierte en tres viajes?
La traza mostró lo esencial. Un solo chown en el kernel invitado se descompone en tres peticiones al host: getxattr para comprobar capabilities, getattr para los bits setuid y setattr para el cambio de propietario en sí. El demonio realiza seis llamadas al sistema y cada una llega a ImageFS. En total, unos 99 µs por operación, a pesar de que virtiofsd ya estaba configurado para el máximo almacenamiento en caché. La raíz del problema es arquitectónica.
¿Qué se sabe sobre Hablar en bloques?
Los ingenieros propusieron mantener el sistema de archivos íntegramente dentro del invitado y dar al host solo un dispositivo de bloques mediante virtio-blk. El disco no sabe qué es un archivo: almacena y entrega fragmentos de datos. La ext4 del invitado comprueba por sí misma los permisos, limpia bits y escribe el cambio en el journal. Al host todo llega más tarde, por lotes, cada pocos segundos. Un chown cuesta unos 2,1 µs en lugar de 99.
Test Frontier LLMs & Autonomous Agents in One Workspace
Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.
Lo esencial de la IA — una vez por semana
Siete historias que de verdad importaron, elegidas a mano. Sin ruido ni notas de prensa.
¡Listo! Revisa tu correo para la confirmación.