Der Linux-Kernel, auf den alle zukünftigen GNU/Linux-Distributionen wie Suse, Debian, Ubuntu und Red Hat Enterprise Linux aufsetzen, ist in der Version 3.8 erschienen. Ein neues Dateisystem F2FS optimiert SSD-Speicher. Gastautor Mathias Menzer durchleuchtet die Linux-Updates der vergangenen zwei Monate.
Die Linux Froundation hat in einer Infografik für Kernel-Verwalter Greg Kroah-Hartman einige Zahlen des vergangenen Jahres zusammengefasst. So bekam Kroah-Hartman über 32’000 E-Mails pro Monat, die Kernel-Mailing-Liste nicht hinzugerechnet. Er verschickte mehr als 40’000 E-Mails. Fast 179’000 Zeilen Code hat er selbst geändert, dazu kommen über 31’000 entfernte Zeilen. 595 Commits wurden von ihm akzeptiert und über 7’000 hat er abgesegnet.
Linux 3.8 Entwicklung
Die bedeutendste Änderung der sechsten Entwicklerversion betrifft die Samsung Notebooks. In Linux 3.8 wird der Treiber «samsung-laptop» abgeschaltet, falls der Linux-Kernel mittels EFI gestartet wurde. Der Hintergrund hierfür liegt im Bekanntwerden eines Fehlers, durch den einige Laptop-Modelle des Herstellers Samsung nach dem Start eines Linux-Systems unbrauchbar wurden. Zwischenzeitlich wiesen jedoch einige Kernel-Entwickler darauf hin, dass das Problem nicht jener Treiber, sondern die UEFI-Firmware selbst sei und der Fehler daher von Samsung behoben werden müsse. Dass es auch unter Windows möglich ist, ein solches Gerät unbrauchbar zu machen, dürfte ihre These untermauern. Die letzte Entwicklerversion RC7 hatte lediglich Korrekturen im Gepäck und war daher gut geeignet, den Entwicklungszyklus abzuschliessen.
Linux 3.8 Release
Nach 70 Tagen Entwicklungszeit stand Linux 3.8 zum Einsatz bereit. Der neue Kernel hat nicht so viele Änderungen aufzuweisen, wie der Vorgänger, er bewegt sich eher in einem normalen Rahmen.
Als erstes bekannt wurde der Wegfall der Unterstützung für die 386-Prozessoren. Eigentlich war dieser Prozessortyp die Wiege für Linux, da Torvalds seinen Kernel ursprünglich hierfür entwickelte. Doch von Sentimentalität war nicht viel zu spüren und so nahm der Linux-Erfinder und Hauptentwickler den Patch auf.
Neues Dateisystem optimiert SSD-Speicher
Mit F2FS steht wieder ein neues Dateisystem zur Verfügung. F2FS ist speziell auf die Anforderungen von Flash-Speichern zugeschnitten, wie sie zum Beispiel in Solid State Drives (SSD) zum Einsatz kommen. Generell existieren bereits mehrere für Flash-Speicher geeignete Dateisysteme wie Logfs oder UBIFS, doch die berücksichtigen nicht den Flash Translation Layer, den SSDs als Zwischenschicht zum System nutzen. Dieser optimiert Zugriffe auf die Flash-Speicherelemente auch für herkömmliche Dateisysteme, sodass der SSD-Datenträger wie ein ganz normales blockorientiertes Gerät gehandhabt werden kann. F2FS kann mit dieser Zwischenschicht umgehen und ihre Optimierungs- und Schutzfunktionen für die Flash-Speicherbausteine mitnutzen.
Mehr Speicherplatz und Zugriffszeit mit Ext4
Auch die altgedienten Dateisysteme wurden mit Verbesserungen bedacht. Ext4 kann nun sehr kleine Dateien direkt in Inodes ablegen. Dort befinden sich normalerweise nur die Metadaten zu Dateien und Verweise auf die Speicherblöcke, in denen die Dateien tatsächlich physikalisch gespeichert sind. Die Inodes sind normalerweise sehr klein (256 Byte in der Standardeinstellung) doch dieser Platz wird meist nicht vollständig gebraucht. Passt in einen solchen Inode die zugehörige Datei noch mit hinein, so wird nicht nur etwas Speicherplatz gespart, da ein ansonsten 4 Kilobyte grosser Block verschwendet werden würde, sondern die Zugriffe auf die Datei erfolgen auch schneller, da die Suche nach dem zugehörigen Speicherblock entfällt.
Erleichterter Austausch von Datenträger für BTRFS
BTRFS ist ein äusserst flexibles und vergleichsweise junges Dateisystem und bringt mit fast jeder Kernel-Version neue Funktionen hervor. Diesmal haben die Entwickler den Austausch physikalischer Datenträger ins Visier genommen. Bislang war es zwar möglich, einen neuen Datenträger in ein BTRFS-Dateisystem einzubinden und daraufhin einen anderen wieder zu entfernen, doch nahmen die darauf folgenden Operationen viel Zeit in Anspruch. Mit der neuen Funktion «replace» wird letzten Endes das Gleiche erreicht, doch arbeitet BTRFS hier wesentlich performanter, solange keine weiteren Datenträger-Operationen anfallen. Der Austausch des Datenträgers erfolgt im laufenden Betrieb, es ist nicht notwendig irgendwelche Operationen zu stoppen oder gar das Dateisystem auszuhängen. Eine Abfrage zum Status des Austauschs und auch der Abbruch ist über das Kommandozeilen-Tool für BTRFS möglich.
Die Speicherverwaltung des Kernels wurde um eine Funktion zum Ordnung halten erweitert. «Huge Pages» (deutsch: «Grosse Seiten») sind spezielle Speicherseiten, die grösser als die üblichen 4KB-Speicherseiten sind, sie werden als spezielle Funktion von der Speicherverwaltung der CPU bereitgestellt. Diese Huge Pages wurden nun erweitert, um «Zero Pages» (deutsch: «Null-Seiten») abbilden zu können, quasi Speicherseiten die vollständig mit Nullen gefüllt sind. Zero Pages werden von Anwendungen genutzt, um Speicherplatz zu reservieren. So kann die Speicherverwaltung letztlich Speicherplatz einsparen, indem einige dieser Seiten nicht zugewiesen werden, sondern stattdessen auf eine bereits existierende Zero Page verwiesen wird.
Die «Cgroups» (Control Groups) sind eine Funktion des Kernels, mittels der die Verteilung von Ressourcen des Systems, wie zum Beispiel Prozessor-Zeit oder Speicher, auf Prozess-Gruppen gesteuert werden kann. Die Cgroups wurden nun erweitert, sodass der Speicher, der zur Verwaltung von Prozessen durch den Kernel benötigt wird, limitiert und abgegrenzt werden kann. Das kann zum einen die Sicherheit des Systems erhöhen, zu anderen die Stabilität, da mit oder ohne Absicht schadhaft geschriebene Programme in ihrem Ressourcenverbrauch wirksam eingeschränkt werden können. Auch die berüchtigten Fork-Bomben [12] sollen hierdurch ihren Schrecken verlieren.
NUMA-Funktionen optimiert
NUMA (Non Uniform Memory Access) ist eine Architektur der Speicheranbindung für Multiprozessor-Systeme, die für jeden Prozessor seinen eigenen lokalen Speicher vorsieht. Dieser kann dann jedoch auch von anderen Prozessoren angesprochen werden, wobei natürlich der Zugriff auf den eigenen Speicher schneller erfolgen kann als auf den anderer CPUs. Insofern ist es günstig, wenn Prozesse auf dem Prozessor ausgeführt werden, in dessen Speicher auch die benötigten Daten liegen. Um dies zu optimieren, wurde in Linux 3.8 nun die Grundlage gelegt. Detaillierte Regeln, nach denen NUMA dann Prozess- und Speicher-Zuweisung steuert, werden im kommenden Kernel folgen.
Spekulationen, dass Linux 3.8 wieder ein Longterm-Kernel werden würde, hat Greg Kroah-Hartman bereits vorzeitig beendet. Er pflege derzeit Linux 3.0 und 3.4 für noch mindestens 2 Jahre, zusätzlich zu den normalen Kernel-Versionen und seiner Tätigkeit bei der Kernelentwicklung. Einen dritten Longterm-Kernel könne er nicht betreuen, ohne noch mehr Haare zu verlieren.
Ein D-Bus im Kernel
Seit sieben Jahren schon steht mit D-Bus unter Linux ein System für die Interprozesskommunikation (IPC) zur Verfügung, das mittlerweile von den gängigsten Desktop-Umgebungen und Anwendungen verwendet wird. Doch D-Bus basiert auf einem Daemon. Greg Kroah-Hartman hegt nun Pläne, ein IPC-System in den Linux-Kernel direkt zu implementieren. Er verspricht sich davon, dass die Kommunikation zwischen Prozessen und Systemkomponenten beschleunigt wird, ausserdem würde es allen Linux-Anwendungen zur Verfügung stehen, sobald nur der Kernel gestartet ist. Damit hätte es auch die besten Aussichten, zu einem neuen Standard zu werden. Zu D-Bus kompatible Schnittstellen sollen es ermöglichen, das IPC-Framework zu wechseln, ohne dass Desktop-Umgebung oder Anwendung etwas davon mitbekommen. Zwar existiert mit AF-Bus bereits ein IPC-System für den Linux-Kernel, doch der eigne sich nach Ansicht von Kroah-Hartman eher für die «verrückten Linux-Entwickler aus der Automobilbranche». So findet sich AF-Bus auch im LTSI-Kernel, jedoch wurde seine Aufnahme in den Mainstream-Kernel von der Entwicklergemeinde bisher abgelehnt.
Keine Secure-Boot-Schlüssel im Kernel
Mit der Anfrage um die Aufnahme einiger Patches wandte sich der Red-Hat-Entwickler David Howells an Torvalds. Konkret ging es darum, dass der Kernel in die Lage versetzt werden sollte, neue Schlüssel für die Verwendung im Zusammenhang mit Secure Boot automatisch zu importieren. Torvalds lehnte die Aufnahme der Patches erst einmal ab, da ihm die neue Funktion und worauf sie aufbaut nicht gefiel. Unter anderem störte er sich daran, dass die Schlüssel aus PE-Dateien extrahiert werden sollen, weil Microsoft nur diese signiere, der Linux-Kernel aber X.509 unterstütze, welches ein Standard für Zertifikate ist. Das Parsen der PE-Binärdateien solle im Userland geschehen. Auch im weiteren Verlauf der Diskussion zeigte sich Torvalds nicht kompromissbereit. Er glaube nicht, dass sich jemand um von vertrauenswürdigen Stellen signierte Schlüssel schere. Da sich auch weitere Entwickler skeptisch zeigten, scheint es eher unwahrscheinlich, dass eine Schlüsselverwaltung in den Kernel integriert wird, die mit den von der Microsoft-Zertifizierungsstelle für die Signierung vorausgesetzten PE-Binärdateien zurechtkommt. Für Linux bedeutet das im Zusammenhang mit Secure Boot, dass zum Beispiel das Aufwachen des Systems nach dem Ruhezustand, was kein eigentlicher Bootvorgang ist, nicht funktioniert oder Fehlermeldungen erzeugt.
Linux 3.9
Knapp 14 Tage nahm Torvalds Merge Requests entgegen, bevor er die erste Entwicklerversion zur Verfügung stellte. Zu den Änderungen, die in 3.9 aufgenommen wurden, zählen zwei neue Architekturen. Arc ist eine 32bit-RISC-Architektur, die für den Einsatz in Unterhaltungs- und Netzwerkgeräten gedacht ist und sehr energieeffizient arbeiten soll. Bei Metag handelt es sich ebenfalls um eine 32bit-Architektur, die als Besonderheit einen Befehlssatz für Signalverarbeitung bereithält und darüber hinaus Multithreading beherrscht. Die Meta-Prozessoren sollen den zeitgleichen Betrieb mehrerer unterschiedlicher Betriebssysteme ermöglichen, die sich verschiedene Aufgaben in einem System teilen, so könnte eines zum Beispiel die Benutzerschnittstelle betreiben, während andere Audio- oder Video-Datenströme behandeln.
Neue RAID-Modi für BTRFS
Das Dateisystem BTRFS wurde um RAID-Funktionen ergänzt und kann nun mit den RAID-Leveln 5 und 6 umgehen, die sich recht ähnlich sind und sowohl hohe Schreib- und Leseleistung als auch die Wiederherstellbarkeit von Daten im Fehlerfall zum Ziel haben. Darüber hinaus wurde der Umgang mit Schnappschüssen des Dateisystems effizienter gestaltet und die Leistungsfähigkeit von fsync, als das Schreiben der im Arbeitsspeicher zwischengelagerten Änderungen auf das Dateisystem, verbessert.
Linux 3.9 RC2 lieferte einige Nachzügler, darunter einen Treiber für den mittels USB 3.0 angeschlossenen Gigabit-Netzwerk-Adapter AX88179/178A. Anstelle einer Beruhigung wurde die Entwicklung dann eher «rasanter»: Sowohl RC3 als auch RC4 fielen von der Zahl der Änderungen eher grösser aus. Auch wenn es sich überwiegend um Fehlerkorrekturen handelte, waren dennoch keine kritischen Probleme dabei.
Ausserdem wurde Ext4 nun mit einer Plausibilitätsprüfung für die Extend Status Trees ausgestattet. Dabei handelt es sich um eine strukturierte Speichermöglichkeit, um Informationen über Extends – aus mehreren Blöcken bestehende, logisch zusammengefasste Speicherbereiche – zu hinterlegen. Die Extend Status Trees können als Grundlage für neue Funktionen dienen und bereits bestehende vereinfachen, wie beispielsweise die Reservierung von Speicherbereichen für sehr grosse Datenmengen.
Ging die Zahl der Änderungen in 3.9 RC5 zwar zurück, so war die Gesamtzahl der geänderten Quelltext-Zeilen so hoch wie seit dem RC1 nicht mehr. Der Grund lag in der Rücknahme eines Patches, mit dem im Entwicklungszyklus für Linux 3.7 der Name eines Moduls für den Seriell-Port-Treiber 8250 geändert wurde. Die daraus resultierenden Probleme erforderten einige Kniffe, die der SUSE-Entwickler Jiri Slaby als so furchtbar ansah, dass er die Änderung zurücknahm und damit eine grosse Menge an Quelltext verschob.
Umgestaltung von Kernel.org
Nachdem sich auf der Webseite von Kernel.org jahrelang nicht viel getan hatte, mussten sich die Nutzer im März gleich zweimal umgewöhnen. Den Anfang machte die Umstellung auf den Seiten-Generator Pelican. Dieser erzeugt statische HTML-Seiten in einem einheitlichen Design, sodass sowohl die Erstellung als auch die Spiegelung der kernel.org-Seiten sehr einfach gehalten wird. Trotzdem kommt das neue Layout übersichtlicher daher. Neuigkeiten finden sich nun unter dem eigenen Punkt «Site News» statt wie bisher am unteren Ende der Webseite. Weitere wichtige Punkte wie die FAQs, und der Überblick über die verschiedenen Releases sind ebenfalls als Unterpunkte prominent aufgeführt.Das aktuelle Aussehen von kernel.org.
Nach wenigen Tagen gab es wieder eine Änderung. Zwar blieb die Seitenerstellung mit Pelican erhalten, doch das bis dahin genutzte Standard-Layout entfiel zugunsten eines eher minimalen Designs. Der Grund hierfür lag darin, dass die Lizenz des CSS-Designs nicht eindeutig ist und die Betreiber daher ein schnell zusammengebasteltes Design in Stellung gebracht hatten, um eventuelle Probleme zu vermeiden. Daher wird derzeit unter webmaster@kernel.org nach Kreativen gesucht, welche die Anpassung der CSS-Vorlagen in Angriff nehmen möchten.
Ebenso wurde das Webfrontend für die Versionsverwaltung des Kernels geändert. Dies übernimmt nun cgit, das sich optisch ein wenig von der bisherigen Oberfläche unterscheidet. Auf der Anwenderseite weichen die Funktionen selbst nur geringfügig ab. So verbirgt sich hinter der Funktion «Log» nun das bisherige «Shortlog», die ausführlichere Variante entfällt.
(Mathias Menzer)
Neueste Artikel von Mathias Menzer (alle ansehen)
- Fortschritte von Linux 4.5: Februar im Kernelrückblick - 29. März 2016
- Linux 4.4 ist da: Jahreswechsel im Kernel-Rückblick - 8. Februar 2016
- Grossumbau für Linux 4.2: Juli im Kernel-Rückblick - 18. August 2015
