Kernel-Log – Was 3.10 bringt (2): Dateisysteme und Storage | heise online

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

Mit Bcache ist ein zweites Framework zum SSD-Caching zum Kernel gestoßen. Kompaktere Metadaten sollen Btrfs beschleunigen. XFS kann seine Dateisystem-Strukturen jetzt mit Checksummen gegen Datenfehler absichern.

vorlesen Druckansicht 4 Kommentare lesen
Lesezeit: 9 Min.
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

Linux 3.10 wird den "Block-Layer Cache" Bcache mitbringen, über den sich ein Datenträger als Cache für andere Datenträger einrichten lässt – etwa eine schnelle SSD als Cache für eine langsamere Festplatte mit mehr Kapazität. Solch ein SSD-Cache kann den Zugriff auf häufig gelesene Daten beschleunigen und zu schreibende Daten zwischenspeichern, um sie später in einem ruhigen Moment auf langsamere Datenträger zu schreiben.

Bcache stammt vom Google-Mitarbeiter Kent Overstreet und wird von seinem Arbeitgeber schon länger produktiv eingesetzt; es ist nach dem bei Linux 3.9 integrierten Dm-Cache das zweite Cache-Framework dieser Art, das in den Linux-Kernel eingeht. Wie Alasdair Kergon, der Betreuer des Device Mappers, vor einem Monat auf dem LinuxTag erläuterte, gehen die beiden Lösungen etwas anders vor, daher sei je nach Umgebungsbedingungen die eine oder andere Lösung die bessere Wahl.

Bcache soll sich besser für Situationen eigenen, wo viele kleine Schreibzugriffe erfolgen, die dann geordnet auf die Festplatte transferiert werden können. Verschiedene Entwickler haben sich in letzter Zeit an Benchmarks der Caching-Lösungen versucht (u. a. 1, 2); oft lief dabei auch die EnhanceIO SSD Caching Software mit, die bislang nicht in den Linux-Kernel integriert wurde. Die Benchmarks ergeben allerdings kein klares Bild und es gab hier und da Kritik an den Messmethoden. Die Ergebnisse und Stimmen von Entwicklern lassen erkennen, dass jede Lösung unter bestimmten Bedingungen gut funktioniert, sich unter anderen aber unerwartet schlecht verhalten kann – offenbar brauchen alle noch ein wenig Reifezeit.

Mehr Infos

Entwicklungsstand

Am Sonntag hat Linus Torvalds die sechste Vorabversion von Linux 3.10 freigegeben. Zum Fertigstellungstermin von 3.10 machte er keine Andeutungen – er erwähnte allerdings, er habe nicht ganz so viel mit Subsystem-Maintainer fluchen müssen. Damit bezog er sich auf die Fluchandrohung in der Freigabe-Mail zum RC5; dort hatte er sich ungehalten gezeit, weil ihm die Entwickler sehr viele Änderungen zur Aufnahme zuschickten.In einer LKML-Diskussion zum RC6, ob fluchen denn förderlich sei, verteidigten Torvalds und andere Kernel-Entwickler ihren direkte Worte – einige der Statements dürften aber nicht ernst gemeint sein.

Das weiterhin experimentelle Dateisystem Btrfs kann jetzt die Metadaten für Extents kompakter ablegen und dadurch ein klein wenig flotter arbeiten. Ältere Kernel verstehen die neuen Dateisystemstrukturen nicht, daher werden sie nicht automatisch genutzt; Anwender müssen das neue Format explizit mit

btrfstune -x

einschalten (1, 2).

Ähnlich muss man auch die experimentellen Funktionen in XFS aktivieren, durch die das XFS-Dateisystem nun zahlreiche Metadaten mit Checksummen versieht, um dort entstandene Inkonsistenzen zu erkennen – Details erläutert die Kernel-Dokumentation zur neuen Funktion.

Ext4 bietet nun einen reservierten, vor versehentlichen Änderungen geschützten Bereich; Bootloader können dort Code ablegen, der beim Systemstart über feste Sektorenangaben geladen werden kann.

Fuse (Filesystem in Userspace) unterstützt nun asynchrones Direct I/O (1, 2) und bietet ein Userspace-Interface für asynchrones I/O; beides soll unter anderem für GlusterFS interessant sein.

Block- und SCSI-Layer bringen nun Funktionen mit, um die zur Laufzeit nutzbaren Stromspartechniken von Storage-Hardware zu nutzen (1, 2).

Der vom Cluster-Dateisystem Ceph verwendete, aber auch unabhängig davon nutzbare Rados Block Device (RBD) unterstützt nun Layering; das ist etwa zum schnellen Klonen von Images interessant, die virtuelle Maschinen als Datenträger verwenden, da das neu erstellte Image auf dem vorhandene aufbauen kann und sich per Copy-on-Write füllt.

Über das neue Fabric-Modul isert lässt sich jetzt ein LIO-iSCSI-Target aufsetzen, das andere Rechner über die iSCSI Extensions for RDMA (iSER) ansprechen können.

Der Treiber für NVM Express (NMVe) beherrscht nun Discard und versteht SCSI-Kommandos inklusive unmap.

Die folgenden Links führen zu einigen kleineren, aber keineswegs unbedeutenden Änderungen:

File Systems

Storage

Ein "C" im Bereich "[  ]" kennzeichnet Commits mit Änderungen an Kconfig-Dateien, welche die Konfigurationsoptionen samt der zugehörigen Hilfetexte enthalten. Mit "I" ausgezeichneten Patches rüsten neue PCI- oder USB-IDs nach; jene mit "D" verändern die dem Kernel beiliegende Dokumentation; Commits mit "N" legen neue Dateien an. Die Zahl vermittelt einen groben Eindruck zur Größe des Patches: Eine "1" kennzeichnet Patches, die inklusive Kommentar zwischen 10 und 20 KByte groß sind; Patches mit einer "9" sind 90 KByte oder größer.

Mehr Infos

Die "Was Linux 3.10 bringt"-Serie

Das Kernel-Log kann bereits jetzt einen Überblick über die wichtigsten Neuerungen der Ende Juni/Anfang Juli erwarteten Linux-Version 3.10 geben, da alle größeren Neuerungen bereits in den ersten beiden Entwicklungswochen integriert wurden; Linux 3.10 befindet sich seit dem in der Stabilisierungsphase, in der die Kernel-Hacker nur selten größeren Änderungen vornehmen.

Über einige der Neuerungen von Linux 3.10 hat das Kernel-Log bereits im Rahmen der Artikelserie "Was 3.10 bringt" berichtet:

  1. Netzwerk

In den kommenden Wochen werden noch Artikel zu den Änderungen an Infrastruktur und Treibern erscheinen.

Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich in den vorangegangenen Kernel-Logs auf heise open. Neue Ausgaben des Kernel-Logs werden auf den Identi.ca- und Twitter-Konten "@kernellog" erwähnt; die englischen, bei den Kollegen von "The H" erscheinenden Übersetzungen auf den Identi.ca- und Twitter-Konten "@kernellog2". Gelegentlich zwitschert der Autor des Kernel-Logs unabhängig davon über einige Kernel-Log-Themen bei Identi.ca und Twitter als "@kernellogauthor". (thl) (thl)