Die Neuerungen von Linux 3.9

Der Kernel kann SSDs als Festplatten-Cache einbinden und Netzwerkverkehr besser auf mehrere CPU-Kerne verteilen. KVM virtualisiert jetzt auch auf der ARM-Prozessoren. Hinzu kommen neue Treiber unter anderem für neue Grafikchips von AMD und kommende WLAN-Chips von Intel.

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

Zehn Wochen nach Linux 3.8 hat Linus Torvalds nun den Kernel 3.9 freigegeben. Damit bleiben der Linux-Erfinder und seine Mitstreiter im gewohnten Rhythmus, denn auch bei den vorangegangenen Kernel-Versionen hat die Entwicklung jeweils rund 70 Tage gedauert.

Eine Neuerung in Linux 3.9 ist das Cache Target "dm-cache", mit dem sich ein Datenträger als Cache für andere Datenträger einrichten lässt – etwa eine schnelle SSD als Schreib-Cache für eine langsamere Festplatte (1, 2, 3). Das Cache-Target kann auf der SSD auch häufig genutzte Daten von der Festplatte bereithalten, um den Zugriff darauf zu beschleunigen. Die als experimentell eingestufte Funktion ist eine Neuentwicklung, die mit einem anderen Ansatzpunkt im Kernel ähnliches leistet wie die älteren, aber unabhängig vom Kernel gewarteten Caching-Lösungen Flashcache und Bcache; letztere wird aber wahrscheinlich in Linux 3.10 einfließen.

Mehr Infos

Im Detail

Bereits in den vergangenen Wochen hat das Kernel-Log in der Serie "Was 3.9 bringt" detailliert über die Neuerungen von Linux 3.9 berichtet:

  1. Dateisysteme und Storage
  2. Infrastruktur
  3. Treiber & Netzwerk

Der nebenstehende Text fasst die wichtigsten Neuerungen dieser Artikel zusammen und gibt einen Ausblick auf Linux 3.10.

Dank der neuen Option SO_REUSEPORT können jetzt mehrere TCP- oder UDP-Sockets auf demselben Port lauschen. Verschiedene Threads eines Webservers können dadurch jeweils einen eigenen Socket öffnen, der auf Port 80 lauscht; dort eingehende Verbindungen verteilt der Kernel gleichmäßig auf die Sockets. Das soll zu einer gleichmäßigen Verteilung der Arbeit auf die Threads und die von ihnen verwendeten Prozessor-Kerne führen.

Laut dem Google-Entwickler Tom Herbert, der diese Erweiterung programmiert hat, kann der neue Ansatz einen bislang in bestimmten Situationen entstehenden Flaschenhals vermeiden, wenn lediglich ein Thread die neuen Verbindungen annimmt und dann an andere Threads verteilt. Der neue Ansatz soll zudem eine stark ungleichmäßige Verteilung der Arbeit auf Prozessorkerne verhindern, die laut Herbert entstehen kann, wenn mehrere Threads auf einem einzelnen Socket lauschen. Details zu diesen Problemen und anderen Aspekten des Ansatzes liefern der Merge-Kommentar zu SO_REUSEPORT und ein LWN.net-Artikel.

Das Btrfs-Dateisystem beherrscht nun nicht mehr nur die RAID-Level 0 und 1, sondern enthält auch die Anfang Februar vorgestellte und als experimentell eingestufte Unterstützung für RAID 5 und 6. RAID-Fähigkeiten direkt im Dateisystem zu implementieren ermöglicht Funktionen, die nur umständlich mit dem klassischen Schichtmodell zu realisieren sind, wo das Dateisystem und das RAID kaum etwas über die Interna des jeweils anderen wissen. Durch die integrierte RAID-Funktionen braucht Btrfs beispielsweise nach dem Ausfall und dem Austausch eines Datenträgers im Btrfs-RAIDs nur die belegten Bereiche zu restaurieren, weil Btrfs diese anhand der Dateisysteminformationen erkennen kann; ein mit Mdadm administriertes Linux-Software-RAID kommt durch die Abstraktion an diese Informationen nicht ran und muss daher das komplette RAID-Volume restaurieren, was länger dauert.

Die Ext-Dateisystementwickler sind ein bei Linux 3.0 entstandenes Performance-Problem im von Ext4 verwendeten Journaling-Layer JBD2 angegangen. CIFS, NFS und eine Reihe weiterer Dateisysteme erhielten Unterstützung für User Namespaces. XFS wurde noch nicht angepasst, daher lassen sich die für Container interessanten User Namespaces bei der Kernel-Konfiguration weiterhin nur aktivieren, wenn XFS deaktiviert ist.