Linux 7.3: Was sich bei btrfs ändert

Zusammenfassung

Der YouTube-Kanal Maple Circuit stellt in seinem Video zum am 18. Oktober 2026 erschienenen Linux 7.3 vor allem die Neuerungen im Dateisystem btrfs vor. Laut dem Pull-Request von David Sterba bringt die Version spürbare Leistungsgewinne bei Direct I/O, Copy-on-Write und fsync sowie geänderte Einhängeoptionen, die Admins vor dem Update kennen sollten. Der Beitrag erklärt die Änderungen anhand der Patches auf der Mailingliste und ordnet die genannten Messwerte ein.

Was Admins vor dem Update prüfen sollten

Der alte Speicherplatz-Cache (space cache v1) ist ab Linux 7.3 standardmäßig abgeschaltet. Seit btrfs-progs 5.15 legt mkfs.btrfs ohnehin den Nachfolger an, den Free Space Tree (v2). Dateisysteme mit v1 funktionieren laut Pull-Request weiter, können aber etwas langsamer sein, weil das Zwischenspeichern der Blockgruppen fehlt.

Die Rettungsoption rescue=usebackuproot, die beim Einhängen auf eine ältere Kopie der Baumwurzel zurückgreift, geht nur noch schreibgeschützt; beschreibbar gilt sie den Entwicklern als zu riskant. Die eigenständige Option usebackuproot, seit Kernel 5.9 als veraltet markiert, ist entfernt. Steht sie noch in /etc/fstab oder in den Kernel-Parametern, gehört sie vor dem Update dort heraus.

Direct I/O ohne Ausweichen auf den Seitencache

Datenbanken und andere Programme, die selbst puffern, schreiben oft mit Direct I/O am Seitencache des Kernels vorbei. btrfs wich dabei bisher in bestimmten Fällen auf gepuffertes Schreiben aus, ein Zugeständnis an die Korrektheit auf Kosten der Geschwindigkeit. Ab 7.3 kopiert btrfs die Daten stattdessen in einen Zwischenpuffer der iomap-Schicht (bounce buffer). Laut Pull-Request steigt die Leistung damit von etwa 50 auf etwa 95 Prozent des theoretischen Maximums.

Weniger doppeltes Kopieren beim Copy-on-Write

btrfs ändert Metadatenblöcke nie an Ort und Stelle, sondern schreibt eine Kopie (Copy-on-Write). Schreibt die Hintergrund-Rückschreibung einen Block weg, den eine laufende Transaktion noch bearbeitet, muss btrfs ihn ein weiteres Mal kopieren; diese Mehrarbeit heißt COW-Amplification. Seit einer früheren Änderung nimmt btrfs solche Blöcke deshalb vorübergehend vom Rückschreiben aus. Die dafür genutzte XArray kostete laut Kernel Test Robot aber 22,6 Prozent Schreibleistung, und beim Löschen großer, stark fragmentierter Dateien konnte das Aufräumen am Ende der Transaktion sekundenlang blockieren.

Leo Martins hat die XArray durch einen festen Puffer mit acht Plätzen ersetzt, den eine CLOCK-Verdrängung verwaltet. Blöcke, die die Transaktion erneut anfasst, bekommen eine zweite Chance; nur einmal benutzte Blöcke fliegen zuerst heraus. Im Test kamen ohne Schutz 6,1 erneute Kopien auf jede Erstkopie, mit dem neuen Puffer 1,6 und mit der alten XArray 1,4. Damit bleibt fast der ganze Schutz erhalten, ohne den Leistungsverlust.

Schnelleres fsync über den Log-Tree

Damit fsync schnell ist, schreibt btrfs nicht die ganze Transaktion, sondern nur die nötigen Metadaten in einen eigenen Log-Tree, aus dem nach einem Absturz wiederhergestellt wird. Schrieben mehrere Prozesse gleichzeitig ins Log, wartete btrfs auf Laufwerken, die es nicht als SSD einstuft, oder mit der Einhängeoption nossd einen Jiffy, also einen Takt des Kernel-Timers von je nach CONFIG_HZ 1 bis 10 Millisekunden. Die Pause sollte weitere Commits bündeln. Filipe Manana hat sie entfernt; laut Pull-Request sinkt die Latenz, und der Durchsatz steigt im Beispiel-Workload etwa auf das Fünffache.

Ein zweiter Patch von Filipe Manana betrifft vollständige fsync-Läufe. Mit der Funktion no-holes, Standard seit btrfs-progs 5.15, speichert btrfs Lücken in Dateien nicht mehr als eigene Einträge, deshalb durchsuchte ein vollständiger fsync alle Extents einer Datei nach Lücken. Ab 7.3 entfällt die Suche, wenn die Datei keine vorab reservierten Extents hat und der belegte Platz mindestens der Dateigröße entspricht. Im Testskript mit 65.536 Extents sank die Dauer von 28,7 auf 5,5 Millisekunden.

Ideen

• Vor jedem Kernel-Update entfernte Einhängeoptionen mit der eigenen fstab abgleichen.
• Rettungsoptionen schreibgeschützt nutzen, nicht im Normalbetrieb.
• Eine kleine Liste mit guter Verdrängung ersetzt fast eine unbegrenzte Datenstruktur.
• Künstliche Wartezeiten zum Bündeln können mehr kosten, als das Bündeln bringt.
• Wer Dateigröße und belegten Platz vergleicht, spart die Suche nach Lücken.
• Automatische Testläufe wie der Kernel Test Robot decken Leistungsrückgänge früh auf.

Einsichten

• Ein Teil der großen Faktoren holt nur Verluste früherer Korrekturen zurück: Erst kostete der Schutz gegen COW-Amplification Leistung, jetzt kommt sie mit einer schlankeren Datenstruktur zurück. Wer Kernel-Versionen vergleicht, muss wissen, gegen welchen Stand gemessen wird.
• Viele Gewinne entstehen durch Abkürzungen für häufige Fälle: keine Lückensuche, wenn keine Lücke möglich ist, kein Warten, wenn ohnehin nichts gebündelt wird. Solche Abkürzungen sind nur so gut wie die Prüfung ihrer Bedingung.
• Das Video erklärt die Patches anschaulich, die belastbaren Messwerte und ihre Grenzen stehen aber in den Commit-Texten auf der Mailingliste.

Fakten

• Linus Torvalds hat Linux 7.3 am 18. Oktober 2026 freigegeben.
• David Sterba schickte die btrfs-Änderungen für 7.3 am 19. August 2026 an Linus Torvalds.
• Der neue Puffer gegen COW-Amplification hat acht Plätze (BTRFS_INHIBITED_EBS_SLOTS).
• Der Kernel Test Robot maß mit der XArray 22,6 Prozent weniger Schreib-IOPS bei zufälligen 4k-Schreibzugriffen.
• Der Free Space Tree (v2) ist seit btrfs-progs 5.15 Standard bei mkfs.btrfs.

Referenzen

• Maple Circuit: Linux Kernel 7.3 | BTRFS IS SOOO BACK! (YouTube)
• David Sterba: [GIT PULL] Btrfs updates for 7.3
• Leo Martins: btrfs: replace writeback inhibition xarray with a fixed inline buffer
• Filipe Manana: btrfs: some optimizations and cleanups for log syncing
• Filipe Manana: btrfs: skip hole detection during full fsync for files without holes
• Maple Circuit: Notizen zu btrfs
• LWN.net: The 7.3 kernel has been released
• Phoronix: Btrfs Ready With More Performance Improvements For Linux 7.3

Kritik

• Titel und Einleitung des Videos überzeichnen: Es spricht von einem der größten Leistungssprünge, die es je von einer Version zur nächsten gesehen habe, doch ein Teil davon holt nur Verluste früherer Korrekturen zurück. So stellt der neue Puffer laut Pull-Request lediglich den Stand vor dem Schutz gegen COW-Amplification wieder her; das Video sagt das an dieser Stelle selbst, der Titel „BTRFS IS SOOO BACK!“ nicht.
• Die Faktoren um 5 stammen aus Beispiel-Workloads; der fsync-Test lief auf einem simulierten Null-Blockgerät (/dev/nullb0) und misst Millisekunden. Für echte Laufwerke im Alltag sagen sie wenig, und das Video nennt für viele Benchmarks selbst Ergebnisse im Bereich der Messungenauigkeit.

Bemerkungen

• Das Video begründet den früheren Ausweichweg bei Direct I/O mit nicht ausgerichteten Schreibzugriffen; der Pull-Request spricht allgemeiner von früheren Abwägungen zwischen Korrektheit und Geschwindigkeit.
• Der größte Benchmark-Gewinn im Video, eine 3,8-fach geringere Latenz bei der Finanzdatenbank TigerBeetle, stammt aus einem Phoronix-Test, der für diesen Beitrag nicht nachgeprüft werden konnte.

Empfehlungen

• Vor dem Update mit grep usebackuproot /etc/fstab /etc/default/grub /proc/cmdline nach der entfernten Option suchen und sie streichen.
• Mit btrfs inspect-internal dump-super <Gerät> prüfen, ob FREE_SPACE_TREE in den compat_ro-Flags steht; fehlt es, läuft noch v1, und ein einmaliges Einhängen mit space_cache=v2 stellt um.
• Datenbanken und Rechner mit Festplatten und vielen fsync-Aufrufen nach dem Update selbst messen, statt sich auf die Faktoren aus den Patches zu verlassen.
• Für Details die Commit-Texte auf lore.kernel.org lesen; dort stehen Testskripte und Einschränkungen.

Video ansehen →

Im Webarchiv suchen

Links zur Originalquelle und zum Webarchiv öffnen einen neuen Tab.