Modal ersetzt virtio-fs durch Blockgeräte und beschleunigt so das Dateisystem seiner VM Sandboxes

Schnell gestartet, langsam im Betrieb

Modal hat kürzlich VM Sandboxes veröffentlicht, die nach Angaben des Unternehmens anspruchsvollere agentische Workloads im großen Maßstab unterstützen, und zwar mit denselben Leistungserwartungen wie die gVisor-basierte Plattform. Das Dateisystem ist ein zentraler Baustein, denn alles in einer Sandbox hängt von dessen Geschwindigkeit ab.

Das Container-Dateisystem des Unternehmens ist ImageFS, das im April 2022 an den Start ging. Laut Modal lädt es vorab nur die minimal nötigen Metadaten, bindet sie über einen Rust-basierten FUSE-Server ein und holt Dateiinhalte bei Bedarf aus einem mehrstufigen, inhaltsadressierten Cache, der vom lokalen Arbeitsspeicher über regionale CDNs bis zum globalen Blob-Speicher reicht. Modal führt es zu einem großen Teil darauf zurück, dass Container in unter einer Sekunde kalt starten. Schreibzugriffe übernimmt OverlayFS, das die schreibgeschützte ImageFS-Schicht mit einer beschreibbaren oberen Schicht zusammenführt.

Container teilen sich den Kernel des Hosts und können ImageFS direkt nutzen. VMs dagegen laufen mit einem vollständigen Gast-Kernel, der die Dateisysteme des Hosts nicht sehen kann. Modal überbrückte diese Lücke zunächst mit virtio-fs, das Dateisystemoperationen des Gasts an einen Daemon auf dem Host namens virtiofsd weiterleitet. VMs starteten aus denselben modal.Image-Objekten mit der erwarteten Kaltstartleistung.

Im Alltag sah es anders aus. Modal berichtet, dass ein rekursives chown von vier Sekunden auf über eine Minute anstieg, dass reale Workloads wie pnpm install und bun install dreimal so langsam wirkten und dass die Leistung von ripgrep regelrecht einbrach.

Warum chown so teuer war

Modal zerlegte die Systemaufrufe seiner bun- und pnpm-Workloads, um daraus synthetische Mikrobenchmarks zu bauen. Verglichen wurde ImageFS direkt auf dem Host, hinter gVisor und über virtio-fs in einer VM. In diesen Tests war stat unter virtio-fs doppelt so langsam, chown sogar um mehr als das Sechsfache schlechter.

Ein Trace von virtiofsd zeigte, dass sich ein einzelnes chown in viele Operationen aufspaltete. Der Gast-Kernel schickte ein FUSE_GETXATTR, um Datei-Capabilities zu prüfen und zu löschen, ein FUSE_GETATTR, um setuid-Bits zu prüfen und zu löschen, und schließlich ein FUSE_SETATTR für die Änderung des Besitzers. Insgesamt bedeutete das drei Roundtrips vom Gast zum Host und sechs Host-Systemaufrufe durch virtiofsd, die jeweils bei ImageFS landeten. Laut Modal dauerte ein chown über virtio-fs 99 µs, selbst wenn virtiofsd so eingestellt war, dass es Operationen möglichst weitgehend zwischenspeichert und zusammenfasst.

Das grundlegende Problem ist nach Modals Darstellung, dass virtio-fs ein geteiltes Dateisystem ist. Metadaten haben eine maßgebliche Instanz, und virtio-fs legt diese auf die Host-Seite der VM-Grenze. Jede Metadatenoperation muss sie also überqueren, auch wenn der Host das Root-Dateisystem der VM nie lesen muss.

In Blöcken sprechen

Modals Antwort bestand darin, das Dateisystem vollständig im Gast leben zu lassen. Der Host hält dann nur noch Bytes vor und liefert sie auf Anfrage aus, so wie ein Blockgerät es tut. Dateisysteme wie ext4 übersetzen zwischen Dateien und Blöcken, und der Gast-Kernel behandelt jedes Blockgerät ohnehin als exklusiv zugeordnet, sodass keine Operation bei jemand anderem den Zustand der Welt erfragen muss.

Mit virtio-blk bleibt dasselbe chown im Gast. Der ext4-Treiber prüft Capabilities und setuid-Bits lokal, führt die Besitzeränderung durch und protokolliert sie in seinem Write-Ahead-Journal. Der Host erfährt erst später davon, wenn ext4 einen Stapel von Schreibvorgängen zurückschreibt. Laut Modal verteilt sich so der Aufwand von Hunderten oder Tausenden Dateioperationen auf einen einzigen Blockbefehl und fällt asynchron an. Für chown über virtio-blk nennt Modal rund 2,1 µs pro Aufruf.

Der Preis dafür: Der Host kann nicht mehr mit dem Dateisystem der VM arbeiten, da er nur noch Blöcke sieht.

ImageFS-blk: Lazy Loading bleibt erhalten

Blockgeräte lösten das Geschwindigkeitsproblem, nicht aber die Kompatibilität mit dem Lazy Loading von ImageFS und der Unterstützung für modal.Image. Würde man mit mkfs.ext4 -d ein Laufwerk aufbauen, müssten sämtliche Image-Inhalte vorab vorliegen, was das Lazy-Konzept zunichtemacht.

Stattdessen holt Modal für ein angefordertes Image nur minimale Dateimetadaten und schreibt damit die Inode-Einträge von ext4 selbst. Jeder Inode enthält die Berechtigungen einer Datei, ihre Größe und eine Liste von Extents, also den Blockbereichen, die ihre Daten darstellen. Der Rest des ext4-Images bleibt sparse, und tatsächliche Blöcke werden erst geliefert, wenn der Gast sie liest. Weil Modal die ext4-Metadaten selbst geschrieben hat, kann es Blockanfragen auf Datei-Bytes in ImageFS abbilden und umgekehrt. Das übernimmt ein Host-Daemon namens ImageFS-blk.

Der vorliegende Ausgangstext endet bei der Beschreibung dieses Daemons, weitere Details zu seiner Implementierung werden hier daher nicht behandelt.

Was das für Nutzer der Sandboxes bedeutet

Für alle, die Workloads in VM Sandboxes betreiben, läuft die Arbeit darauf hinaus, dass Paketinstallationen, Suchvorgänge und metadatenintensive Operationen keinen Preis für die VM-Grenze zahlen sollen. Modals eigene Messungen zeigen, welche Lücke geschlossen wurde: 99 µs gegenüber rund 2,1 µs für ein einzelnes chown. Das Unternehmen erklärt, das Ziel sei, VM Sandboxes auf demselben Leistungsniveau zu halten wie die Container-Plattform.