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

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

Einige von Torvalds hervorgehobene Änderungen an Interna des Block Layer sollen Performance und Skalierbarkeit verbessern. In diesen Bereichen legt auch das Ext4-Dateisystem zu. Das weiterhin experimentelle Btrfs beherrscht nun Batched Discard und LIO (Linux-Iscsi.org) eine Loopback-Funktion.

vorlesen Druckansicht 5 Kommentare lesen
Lesezeit: 20 Min.
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

Kernel-Hacker Andi Kleen hat Ende vergangener Woche eine Patch-Serie auf der LKML veröffentlicht, die ein alle Dateisysteme betreffendes Performance-Problem beseitigt. Es hat seinen Urspung beim Zusammenspiel zwischen Virtual File System (VFS) und der Security-Infrastruktur des Kernels und ist ein unerwünschter Seiteneffekt der bei 2.6.38 eingeflossenen Optimierungen am VFS. Torvalds zeigte sich überaus interessiert und nahm einen der Patches gleich in den Hauptentwicklungszweig auf; eine auf dem zweiten Patch von Kleen aufbauende Korrektur folgte am Ostermontag und soll das Problem beim Zusammenspiel mit SELinux beseitigen. Die Kernel-Hacker diskutieren noch, ob diese Patches wie von Torvalds angeregt in einen 38er-Stable-Kernel einziehen sollen.

Den fünften Release Candidate von Linux 2.6.39 hat Torvalds noch nicht veröffentlicht – vermutlich dürfte er in Kürze erscheinen, denn der RC4 ist bereits über eine Woche alt. Das Kernel-Log nimmt die fortschreitende Entwicklung des 39er-Kernels zum Anlass, die Mini-Serie "Was 2.6.39 bringt" mit der Beschreibung der Neuerungen rund um Storage-Infrastruktur und Dateisysteme fortzusetzen. Den Anfang dieser Artikel-Reihe hatte eine Übersicht der Änderungen an Netzwerk-Treibern und -Infrastruktur gemacht; in den kommenden Wochen werden noch Artikel zur Grafik-Treibern, Architektur-Code, Infrastruktur und Treibern für andere Hardware folgen.

Jens Axboe hat einige Interna im von ihm betreuten Block-Subsystem erheblich umstrukturiert. Das delegiert einige Aufgaben beim Schreiben von einem Geräte-spezifischen Puffer näher zum Code, der die Daten schreiben möchte (u. a. 1, 2). Das soll die Skalierbarkeit steigern und dadurch die Performance beim Einsatz der heute schnellsten Datenträger verbessern.

Dieses "New Block Device Plugging Model" war die einzige Änderung, der Torvalds in der Mail zur ersten Vorabversion von 2.6.39 besondere Aufmerksamkeit zukommen ließ; der Ansatz vermeide Sperren in einem viel genutzten Code-Pfad, mache den Code sauberer und sei überhaupt eine "wirklich gute Idee". Einige Hintergründe zur Motivation und der Funktionsweise erläutert Axboe in seinem Haupt-Git-Pull-Request; eine allgemeine Erklärung der Interna des Block Layer liefert er im LWN.net-Artikel "Explicit block device plugging".

Torvalds erwähnte in der Freigabe-Mail zum RC1, der Kernel habe durch einen Fehler an den Plugging-Änderungen zwischenzeitlich XFS-Dateisysteme "zum Frühstück verspeist". Auch nach dem RC1 gab es noch einige Probleme, die jedoch nicht so schwerwiegend waren – die meisten wurden zum RC4 beseitigt. Das zeigt, dass Datenverlust nicht gerade unwahrscheinlich ist, wenn man während des Merge Window den aktuellen Entwicklungsstand von Linux testet. Typischerweise beseitigen die Kernel-Hacker solche gravierenden Probleme allerdings sehr schnell. In der Stabilisierungsphase und speziell nach dem zweiten Release Candidate sind solch schlimme Fehler allerdings sehr selten: Die Kernel-Hacker versuchen sie von vorn herein zu vermeiden, um die ohnehin schon raren Tester nicht zu verschrecken.

  • Die bei 2.6.38 integrierte Target-Implementierung LIO (Linux-Iscsi.org) haben die Kernel-Hacker um das Modul tcm_loop erweitert, das eine lokale SPC-4-SCSI Emulation für beliebige Raw-Devices ermöglicht. Durch eine weitere Änderung sind in Zukunft einige allgemeine oder speziell zur statistischen Auswertung interessante Informationen via Sysfs abfragbar.
  • Die Storage-Treiber ahci und ata_piix des 39er-Kernels unterstützen bereits jetzt die SATA-Adapter der "Panther Point"-Chipsätze (1, 2), die Intel vermutlich Anfang 2012 zusammen mit neuen Prozessoren einführen wird.
  • Der AHCI-Treiber des 39er-Kernels spricht jetzt Marvells PCIe-SATA-6G-Controller 88se9125 an (1, 2).
  • Das mit RAID 0 vergleichbare Funktionen bietende Device-Mapper-Target Striped unterstützt nun "Merge Methods", was die Performance beim Einsatz von XFS und Ext4 in bestimmten Situation etwas steigert. Der Device Mapper (DM) bringt nun das Target Flakey mit, das wie das Linear-Target funktioniert, aber zu Testzwecken gelegentlich Fehler einstreut.
  • Zum Kernel stieß der Treiber bnx2fc, der einige Aufgaben für die Kommunikation über FCoe (Fibre Channel over Ethernet) an den NetXtreme II 57712 FCoE-Controller von Broadcom übergibt.
  • Der Treiber aacraid unterstützt nun eine neue, "SRC-basierte" Controller-Familie von PMC-Sierra, die ein "0x28b" genanntes Interface aufweisen; das beherrschen laut einer Patch-Beschreibung die "Series-6-Chips", die auf RAID-Controllern mit "Advanced ROC (RAID-on-chip)" sitzen und Daten mit 6 GB/s übertragen.
  • Das SCSI-Subsystem bietet nun bessere Unterstützung für die in der T10-Spezifikation SBC3r26 definierten Schnittstellen zum Logical Block Provisioning. Sei informieren SSDs oder Netzwerk-Speicherlösungen mit Thin Provisioning über das SCSI-Kommandos WRITE SAME und dessen UNMAP-Bit über freigewordene Speicherbereiche (1, 2); einige Hintergründe dazu liefern die "Solid-State Disk Deployment Guidelines" im Storage Administration Guide von RHEL 6.1 und der Artikel "Disk und Chips – Flash-SSDs in Servern und Storage-Systemen" in der iX 5/10.
  • Zum vornehmlich im Embedded-Bereich verwendeten Subsystem für Memory Technology Devices (MTD) stieß ein Treiber, um MTD-Geräte zum Swappen zu nutzen.
  • Es gab verschiedene Änderung an der Replikationslösung DRBD, wodurch die Kernel-Implementation bei 2.6.39 den Stand von DRBD 8.3.10 erreicht.

Ext4 nutzt in Zukunft standardmäßig die mblk_io_submit "Multiple Page-IO Submissions", was Performance und Skalierbarkeit erheblich verbessern soll. Der dahinter stehende Code war bei 2.6.37 zum Kernel gestoßen; die Ext-Entwickler legten die Funktion aber kurz vor der Fertigstellung dieser Linux-Version in der Voreinstellung lahm, da sie in einer bestimmten Situation zu Datenschäden führte; der Fehler wurde während der Stabilisierungsphase von 2.6.38 behoben. Ein größere Aktualisierung erfuhr die Ext4-Dokumentation des Kernels, die nun einige der neueren Mount-Parameter erläutert und die Dateien aufschlüsselt, die der Ext4-Code im Procfs und Sysfs anlegt.

Das weiterhin experimentelle Dateisystem Btrfs beherrscht ab 2.6.39 Batched Discard – eine bei 2.6.37 eingeführte Funktion, um SSDs und mit Hilfe von fstrim ab und zu über ungenutzte Speicherbereiche zu informieren. Via FS_IOC_SETFLAGS lässt sich nun datei- und verzeichnisweise festlegen, ob Btrfs "Copy on Write" (COW) oder Kompression nutzen soll. Laut Commit-Kommentar ist das eine Interims-Lösung, bis das VFS Funktionen bietet, um solche Eigenschaften festzulegen. Chris Mason erläutert diese beiden und einige weitere Btrfs-Änderungen in seinem Haupt-Git-Pull-Request zum von ihm betreuten Btrfs.

Über den neuen Syscall Sys_syncfs können unprivilegierte Userspace-Anwendungen den Kernel anweisen, alle zwischengespeicherten Daten eines einzelnen Dateisystems wegzuschreiben. Bislang ließ sich eine Synchronisierung nur systemweit anstoßen – Anwendungen haben das aber gemieden, weil es sonst zu kurzzeitigen Hängern kommt, wenn etwa ein NFS-Server nicht erreichbar ist.

Der Syscall Open kennt nun das Flag O_PATH, um einen "location only" File Descriptor zu erstellen, bei dem lediglich der Pfad aufgelöst wird; solche sind etwa zur Verwendung mit verschiedenen auf "at()" endenden Syscalls interessant. Ebenfalls neu ist das für Dateisysteme im Userspace interessante "Open by Handle", das LWN.net näher erläutert.

  • Das neue Dateisystem Pstore bietet Zugriff auf "Platform Persistent Storage" – nichtflüchtige und zumeist kleine Speicherbereiche, die manche Systeme mitbringen, damit Betriebssysteme dort im Falle eines Absturzes Daten zur Crash-Analyse ablegen können. Hintergründe dazu liefert LWN.net im Artikel "Persistent storage for a kernel's 'dying breath'".
  • Die wichtigsten Neuerungen an XFS erläutert Christoph Hellwig im mittleren Drittel des "XFS status update for March 2011" (im erste Drittel spricht er von 2.6.39, meint aber 2.6.38). Dort erklärt er, der 39er-Kernel bringe vergleichsweise wenig erwähnenswerte XFS-Neuerung; die bedeutsamste sei das standardmäßige Einschalten des Delaylogs, was Metadata Performance and Skalierbarkeit verbessere.

Viele kleinere, aber keineswegs unbedeutende Neuerungen finden sich in der folgenden Liste mit den englischen Commit-Überschriften der jeweiligen Änderung. Die Einträge verlinken genau wie viele der Verweise im vorangegangenen Text auf das Webfrontend des von Linus Torvalds gepflegten Git-Zweigs mit den "offiziellen" Kernel-Quellen auf Kernel.org. Der über diese Links angezeigten Commit-Kommentar und der darunter ausgegebene Patch liefern zahlreiche weitere Informationen zur jeweiligen Änderungen.

Vor jedem Link finden sich in eckigen Klammern einige Buchstaben und Zahlen. Ein "C" kennzeichnet Patches mit Änderungen an Kconfig-Dateien, welche die Konfigurationsoptionen samt der zugehörigen Hilfetexte enthalten, die bei der Kernel-Konfiguration über "make menuconfig" oder "make xconfig" angezeigt werden. Ein "D" steht bei Patches, die die Dokumentation verändern, die im Kernel-Zweig unterhalb von Documentation/ liegt. Ein "N" weist Änderungen aus, die eine neue Datei anlegen. Die Zahl vermittelt einen groben Eindruck zur Größe des Patches: eine "1" kennzeichnet Änderungen, die inklusive Kommentar zwischen 10 und 20 KByte groß sind, eine "2" für solche, die zwischen 20 und 30 KByte Umfang haben; Änderungen ohne Zahl sind kleiner als 10 KByte, Patches mit einer "9" hingegen 90 KByte oder größer.

Btrfs

Ext[234]

Various

Block

Libata

SCSI

Various

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)