Kernel-Log – Was 3.3 bringt (2): Dateisysteme und Storage

Der Btrfs- und MD-Code bietet neue Möglichkeiten, ein RAID unter Erhalt der Daten umzubauen. Ext4-Dateisysteme lassen sich nun schneller vergrößern.

In Pocket speichern vorlesen Druckansicht 6 Kommentare lesen
Lesezeit: 9 Min.
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

Die Kernel-Entwickler haben für Linux 3.3 eine Reihe von Umbauten und Erweiterungen am Balancing- und Restriping-Code von Btrfs vorgenommen, der für das Umverteilen von Daten innerhalb von Btrfs-Laufwerken zuständig ist (1, 2, 3, 4, 5, 6). Durch diese Änderungen lassen sich mit Btrfs erzeugte RAIDs umbauen – etwa von einem RAID 1 in ein RAID 10. Solch eine Migration lässt sich durch den neuen Code nun auch pausieren, abbrechen oder nach einem Absturz fortsetzen.

Neu sind auch einige optional einkompilierbare Btrfs-Funktionen, durch die das weiterhin experimentelle Dateisystem Integritätsprüfungen im Betrieb durchführt (1, 2). Das kann bei der Analyse von Situationen helfen, die zu inkonsistenten Dateisystemen führen. Der Hilfetext der zugehörigen Kernel-Konfigurations-Option betont, dieser Funktion sei "gefährlich" und man sollte sie im Normalbetrieb nicht verwenden.

Mehr Infos

Entwicklungsstand

Die Entwicklung von Linux 3.3 schreitet mit der Freigabe des vierten RCs weiter voran. Nachdem die dritte Vorabversion keine sonderlichen Überraschungen gebracht hatte, erschien die vierte leicht verspätet: Torvalds und einige andere Entwickler haben einem Fehler nachgespürt, das sich unter anderem in Übertragungsfehler beim Einsatz von WPA2 zeigte. Das mit dem RC4 behobene Problem trat allerdings nur auf, wenn ein 32-Bit-Kernel auf einem x86-Prozessor mit AES-NI-Unterstützung lief, weil ältere Kernel dort den Zustand der FPU (Floating-Point Unit) in bestimmten Situationen nicht korrekt wiederhergestellt haben.

Der Ext4-Code erhielt einen neuen Mechanismus zum Anpassen der Größe von Ext4-Dateisystemen (u. a. 1). Bei ihm kümmert sich nicht vornehmlich ein Userspace-Programm um die Größenanpassung, sondern der Kernel selbst. Laut Messungen, die ein Entwickler mit einer frühen Version des Codes durchgeführt hat, benötigte der neue Mechanismus lediglich 3,5 Sekunden, um ein 20 GByte großes Laufwerk auf 230 GByte aufzuziehen; der bisher verwendete Ansatz brauchte über 5 Minuten. Die neue Technik unterstützt aber einige der neueren Ext4-Techniken bislang nicht – darunter die bei Linux 3.2 eingeführten Big Allocations (Bigalloc).

Die XFS-Entwickler haben die Mount-Option "nodelaylog" entfernt. Mit ihr ließ sich eine ältere Arbeitsweise beim Schreiben von Log-Daten aktivieren, die der Kernel seit einiger Zeit nicht mehr standardmäßig nutzt. Der neuere Ansatz hat nach Aussage von XFS-Entwicklern ein Performance-Problem rund um das Schreiben von Metadaten beseitigt. Einige Hintergründe dazu finden sich in der Video-Aufzeichnung des Vortrags "XFS: Recent and Future Adventures in Filesystem Scalability", den Red-Hat-Entwickler Dave Chinner auf der diesjährigen linux.conf.au gehalten hat; LWN.net hat diesen Vortrag zusammengefasst.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.