Modal accélère bun install de 12 fois dans ses sandboxes VM en remplaçant virtio-fs par un disque bloc

Si vous construisez des sandboxes pour agents, vous le savez : un démarrage rapide ne signifie pas un travail rapide. L'agent installe des dépendances, lance grep sur le dépôt, modifie les droits de milliers de fichiers. Tout cela repose sur le système de fichiers. Les ingénieurs de Modal racontent comment ils s'y sont brûlés lors du lancement de VM Sandboxes et ce qu'ils ont fait.

Démarre vite, travaille lentement

Modal dispose depuis longtemps d'ImageFS, un système de fichiers distribué à chargement paresseux pour les conteneurs. Il ne récupère à l'avance que l'index des métadonnées, et va chercher le contenu des fichiers à la demande dans un cache à plusieurs niveaux : mémoire, CDN régionaux, stockage global. Les conteneurs démarrent donc en moins d'une seconde. Pour l'écriture, une couche OverlayFS est posée par-dessus.

Pour les machines virtuelles, la logique est la même : la VM a son propre noyau invité et n'a pas d'accès direct à ImageFS sur l'hôte. Le pont standard est virtio-fs, où le démon virtiofsd sur l'hôte applique les requêtes de l'invité à un répertoire partagé. Il a été pointé vers ImageFS, et le démarrage est resté identique.

Mais au travail, tout s'est effondré. Un chown récursif a pris plus d'une minute au lieu de quatre secondes. bun install et pnpm install ont ralenti d'environ trois fois, et ripgrep a le plus chuté. Sur un microbenchmark de 100 000 appels, chown a pris 9,87 s contre 2,31 s sous gVisor et 1,58 s sur ImageFS nu.

Pourquoi un chown devient trois allers-retours

Le traçage a montré l'essentiel. Un seul chown dans le noyau invité se décompose en trois requêtes vers l'hôte : getxattr pour vérifier les capabilities, getattr pour les bits setuid et setattr pour le changement de propriétaire lui-même. Le démon effectue six appels système, et chacun atteint ImageFS. Au total, environ 99 µs par opération, alors que virtiofsd était déjà configuré pour un cache maximal.

La racine du problème est architecturale. virtio-fs est un système de fichiers partagé : pour les métadonnées, il faut à chaque fois consulter l'autorité de l'autre côté de la frontière de la VM. Alors que l'hôte n'a absolument pas besoin du contenu du système de fichiers racine de la machine virtuelle.

Parler en blocs

Les ingénieurs ont proposé de garder le système de fichiers entièrement dans l'invité et de ne donner à l'hôte qu'un périphérique bloc via virtio-blk. Le disque ne sait pas ce qu'est un fichier : il stocke et restitue des morceaux de données. L'ext4 de l'invité vérifie elle-même les droits, efface les bits et écrit la modification dans le journal. Vers l'hôte, tout part plus tard, par lot, toutes les quelques secondes. Un chown coûte environ 2,1 µs au lieu de 99.

La difficulté est que mkfs.ext4 exige que toute l'image soit présente, ce qui tue le chargement paresseux. L'équipe écrit donc elle-même les enregistrements d'inodes ext4 à partir des métadonnées de l'image et laisse le reste creux. Le démon ImageFS-blk transforme les requêtes de blocs en lectures de plages de fichiers depuis ImageFS, et place les blocs écrits dans un fichier creux (sparse) en les marquant dans une table de bits. C'est l'équivalent d'OverlayFS, mais au niveau des blocs. Au passage, une vieille douleur disparaît : la copie sur écriture travaille sur un bloc, et non sur tout le fichier. Dans le pire des cas, OverlayFS copiait des gigaoctets pour quelques octets.

Résultats et revers de la médaille

Voici les chiffres (virtio-fs, ImageFS, ImageFS-blk) :

• bun install : 12,5 s, 3,1 s, 1,07 s ;
• ripgrep sur le dépôt Linux à cache chaud : 6,03 s, 3,77 s, 0,18 s ;
• SQLite speedtest1 : 543 s, 290 s, 43 s ;
• pgbench en lecture seule : 98 k, 137 k, 230 k TPS ;
• pgbench lecture et écriture : 8,3 k, 11,9 k, 18,8 k TPS.

ImageFS-blk a même dépassé l'ImageFS d'origine : les métadonnées ne passent plus par FUSE. Le démarrage à froid en moins d'une seconde a été conservé.

L'approche a un coût. L'hôte ne voit plus les fichiers à l'intérieur de la VM : il ne connaît que des blocs, et les snapshots sont calculés à partir de l'ensemble des blocs modifiés. De plus, à cache froid, ripgrep sur le dépôt prend 8,53 s avec ImageFS-blk contre 4,47 s avec l'ImageFS ordinaire. Là, le schéma par blocs est perdant. Tous les chiffres ont été obtenus par Modal elle-même sur son matériel, sans vérification indépendante.

Que faire de tout cela

Si vous construisez des micro-VM pour des agents ou de la CI, n'adoptez pas virtio-fs comme système de fichiers racine par défaut. Pour une sandbox isolée où l'hôte ne lit pas les fichiers de l'invité, un système de fichiers partagé est une taxe inutile sur chaque opération de métadonnées. Testez non seulement le cold start, mais aussi votre scénario réel : installation de paquets, recherche dans le code, chown et base de données. C'est précisément là que se révèle l'écart d'un facteur 10.