Kernel-Log – Was 2.6.38 bringt (4): Storage

Seite 2: Device Mapper, Staccato, Perlen

Inhaltsverzeichnis

Über neue Schnittstellen kann der Device Mapper auf Funktionen des Subsystems MD (Multiple Devices) zur Verwaltung von Software-RAIDs zugreifen, die für die RAID-Level 4, 5 und 6 zuständig sind. Zusammen mit einer frischen Version von Dmraid sollte das langfristig für eine bessere Unterstützung der von vielen Mainboard-Chipsätzen gebotenen Host-RAID-5-Funktionen sorgen, für die bislang spezielle Kernel-Patches erforderlich waren, die manchen Distributionen nicht beiliegen.

Durch den Einsatz von mehreren Workqueues in Dmcrypt nutzt der Device Mapper (DM) nun Multi-Core-Prozessoren besser und sollte so flotter ver- und entschlüsseln. Neu sind auch Multi-Key-Fähigkeiten für Dmcrypt, um verschiedene Blöcke eines Datenträgers mit unterschiedlichen Keys zu verschlüsseln; die ebenfalls neue Unterstützung für den Loop-AES Block Device Encryption System setzt darauf auf. Der DM-Code für Mirroring/RAID1 leitet ab 2.6.38 Discard-Informationen weiter und informiert so Datenträger über freigewordene Bereiche. Zwei von Mikulas Patocka eingebrachte Änderungen verbessern bei bestimmten Umgebungsbedingungen die Performance des Device Mappers, was er mit Messwerten in den Commit-Kommentaren zeigt (1, 2)

  • Der Cgroups Blkio Controller zum Begrenzen der Datenträgerverwendung unterstützt bei bestimmten Funktionen nun eine vereinfachte hierarchische Gruppierung – Details dazu liefert LWN.net im Artikel "Hierarchical group I/O scheduling", der eine andere Patch-Serie beschreibt, die einige Probleme des für 2.6.38 eingebrachten Ansatzes beseitigen soll.
  • Block-Subsystem-Maintainer Jens Axboe hebt in seinem Haupt-Git-Pull-Request noch einige Performance-Optimierungen am standardmäßig verwendenden I/O-Scheduler CFQ (Completely Fair Queuing) hervor (u.a.  1, 2)
  • Der Code für Multiple Devices (MD) bietet nun Funktionen zum Überführen eines RAID 1 in ein RAID 0.
  • Im Merge Window von 2.6.38 zog ein Patch ein, durch den das Block-Layer sicher stellen sollte, das auf ihm aufbauende Subsysteme das Readonly-Flag beherzigen. Das führte aber zu einigen in einem ab Donnerstag den 3. März frei erhältlichen LWN.net-Artikel erläuterten Problemen, sodass das Ganze fürs Erste wieder verworfen wurde.
  • Der Treiber megaraid_sas spricht ab 2.6.38 auch die MegaRAID-Chips 9265 und 9285 an.
  • Zum Libata-Subsystem stieß ein Treiber für den ATP8620 von Acard.
  • Der für Emulex-Chips zuständige LightPulse Fibre Channel SCSI Driver lpfc bietet nun Unterstützung für SLI4 FC Discovery.

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", "make xconfig" und ähnliche Werkzeuge 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" steht für Ä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.

Block-Layer, Libata, Infiniband

SCSI

MMC, MFD, MTD und Co.

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)