En vivo 18.11 · Cohorte 318 nov, 19:00 MSK — taller práctico gratuito de agentes IA · Cohorte 3 en vivo inicia 23.11Taller 18 nov →Cohorte 3 (23.11)
LanzamientoAnálisis · En radarModal Blog→ original

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
Modal acelera bun install 12 veces en sus sandboxes de VM al sustituir virtio-fs por un disco de bloques
Fuente: Modal Blog. Collage: Hamidun News.
Escuchar artículo
Ficha técnica y cifras clave
ParámetroDatos
Fuente originalModal Blog ↗
Editor jefe
Bun installde 12,5 a 1,07 s, es decir, 12 veces más rápido
Pgbench con escriturade 8,3 a 18,8 mil TPS; SQLite: de 543 a 43 s
Inconvenienteripgrep en frío es más lento que con ImageFS: 8,5 frente a 4,5 s

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.

Historia

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.

ZK
Zhemal Khamidun — CPO de Alpina Digital, product manager de AlpinaGPT. Crea productos de IA desde 2019. Hamidun News es un proyecto personal que creció hasta ser un agregador en producción con más de 6.000 lectores.
✦ Unified AI Workspace · Nomad

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.

Try Nomad AI →Launch Nomad Agent
¿Qué te parece?
Cargando comentarios…