Ein Dateisystem-Benchmark, der die Ausfälle misst: degradierte Arrays, volle Platten, fsync-Ausläufer

Die meisten Dateisystem-Vergleiche sind eine Tabelle sequenzieller Durchsätze, einmal gemessen, auf einer Maschine, von jemandem mit Vorliebe. Hier läuft stattdessen eine CI-Suite dauerhaft: 593 aufgezeichnete Durchläufe, der jüngste vom 18. September, mit Verlaufskurven pro Layout über Monate statt einer Momentaufnahme vom Nachmittag.

Verglichen werden das klassische Paar und die Copy-on-Write-Riege — ext4, XFS, ZFS, Btrfs, bcachefs — und zwar nicht als nackte Dateisysteme, sondern als Layouts: Einzelgerät, md-RAID10, LVM-RAID10, eine LVM-Integritätsvariante, XFS auf einem ZFS-Volume, ZFS-Mirror sowie RAIDZ1/RAIDZ2, Btrfs RAID1 und RAID6, bcachefs mit zwei Replikaten und mit Erasure Coding, dazu eine LUKS-Variante. Diese Achse ist entscheidend, denn im Betrieb fährt niemand ein Dateisystem — man fährt ein Dateisystem auf einem bestimmten Stapel.

Lesenswert macht das Projekt, welche Phasen es misst. Neben gewöhnlichem Durchsatz stehen die Fälle, die andere Benchmarks auslassen, weil sie unbequem aufzusetzen sind:

• Überschreiben nach dem Snapshot — Schreiben in eine gerade geschnappschottete Datei, wo jeder Schreibvorgang die geteilten Extents auflösen muss. Diese Strafe zahlt jede Snapshot-Installation täglich, und in keiner Durchsatztabelle taucht sie auf.
• Zufälliges Schreiben im degradierten Zustand — ein Gerät absichtlich ausgefallen (zpool offline, mdadm --fail, abgehängtes Loop-Gerät mit degradiertem Mount), gemessen wird, während die Platte fehlt. Genau in diesem Zustand ist man, wenn Leistung plötzlich zählt.
• Verhalten bei ENOSPC — bis zum harten ENOSPC füllen, dann eine Datei löschen und prüfen, ob der Platz zurückkommt und ein neuer Schreibvorgang gelingt. Ob ein volles Dateisystem sich durch Löschen retten lässt, ist eine echte Betriebseigenschaft, und die CoW-Systeme waren historisch die interessanten Fälle.
• fsync-Ausläufer bei p99 und p99,9 statt eines Mittelwerts — die Zahl, von der eine Datenbank tatsächlich lebt.

Was das bedeutet

Der Vorbehalt oben auf der Seite ist die wertvollste Zeile. Die Läufe nutzen Loop-Geräte auf geteilten, kurzlebigen Cloud-VMs, eine VM je Dateisystem, und der Autor sagt es deutlich: Formen und Verhältnisse vergleichen, keine absoluten MB/s — dazu trägt jeder Job einen Kalibrierungsanker, damit Drift der darunterliegenden Hardware sichtbar bleibt. Ein Benchmark, der benennt, was er nicht tragen kann, nützt mehr als einer mit sauberen Zahlen, dessen Grenzen man selbst herausfinden darf.

Die Fehlerfälle messen, nicht den Glücksfall — dieselbe Regel gilt für die eigenen Systeme. Die sequenzielle Schreibrate eines unbelasteten Arrays überrascht niemanden. Überraschungen kommen, wenn eine Platte fehlt, wenn das Volume voll ist, wenn der stündliche Snapshot jeden folgenden Schreibvorgang teurer macht. Wer seine Kapazitätsplanung auf Zahlen aus dem gesunden Zustand baut, plant für genau den Zustand, in dem die Planung nie gebraucht wird.

Und eine Verlaufskurve schlägt eine Messung. Weil die Suite dieselben Layouts wiederholt fährt, erscheint eine Regression in Kernel oder Dateisystem als Stufe im Diagramm statt als Streit auf einer Mailingliste. Das ist der Unterschied zwischen einem Benchmark und einem Monitor — und der Grund, das Projekt eher zu abonnieren als einmal zu lesen.

Der Code steht unter Apache-2.0, die Ergebnisdaten unter CC BY 4.0; Methodik und die Anleitung für echte Hardware liegen im Repository.