Kernel-Log: Morton stellt Aufnahme des Xen-Dom0-Codes in Frage; Dateisysteme für SSDs

Inhaltsverzeichnis

In einer Antwort auf kürzlich an die Linux-Kernel Mailing List (LKML) zur Begutachtung eingesandte Xen-Dom0-Patches fragt Andrew Morton, ob es überhaupt noch sinnvoll sei, die Kernel-Erweiterungen zum Betrieb als federführende Xen-Domäne (Dom0) in den Hauptentwicklungszweig von Linux aufzunehmen. So stellte er die Frage, ob Xen nicht immer noch der "alte" Weg zur Virtualisierung sei, während sich die Welt in eine "neue" Richtung zu KVM bewege; auch stellt er zur Diskussion, ob die Linux-Entwickler eine Aufnahme der Xen-Dom0-Unterstützung in drei Jahren vielleicht bereuen würden ("I hate to be the one to say it, but we should sit down and work out whether it is justifiable to merge any of this into Linux. I think it's still the case that the Xen technology is the "old" way and that the world is moving off in the "new" direction, KVM? In three years time, will we regret having merged this? ").

Daraus entstand eine Debatte um das Für und Wider sowie die verschiedenen Vor- und Nachteile von Xen und KVM. Der langjährige Xen-Entwickler Jeremy Fitzhardinge, der von ihm und anderen entwickelten Xen-Dom0-Patches an die LKML geschickt hatte , warb in dem Rahmen stark für Xen. Er bekam aber auch von anderen bekannten Linux-Entwicklern einiges an Gegenwind. Unter anderem von Nick Piggin und Ingo Molnar – letzterer dürfte als einer der Verwalter des Kernel-Codes zur Unterstützung der x86-Architektur bei der Entscheidung um die Aufnahme der Xen-Unterstützung ein gewichtiges Wörtchen mitzureden haben. Getroffen ist eine Entscheidung aber wohl noch nicht – trotz der von Morton angeregten Diskussion und den Einwürfen von anderen Kernel-Hackern ist es daher durchaus möglich, dass vielleicht schon die übernächste Linux-Version 2.6.30 Xen-Dom0-Code auf Basis dieser Patches bieten wird.

Wie es dazu kam

Beim Entwicklungsmodell des Linux-Kernels sind Prognosen ohnehin sehr schwierig, da viele Entwickler und nicht zuletzt Linus Torvalds eine Aufnahme von Patches erheblich beschleunigen oder verlangsamen können. Ursprünglich hatte Morton bereits vor vier Jahren eine baldige die Aufnahme der Xen-Unterstützung in den Linux-Kernel prophezeit. Die Kernel-Entwickler waren jedoch schon zu der Zeit mit einigen Eigenschaften an der Integration in den Kernel-Quellen unzufrieden und forderten Änderungen vor der Aufnahme.

Während die Xen-Entwickler daran arbeiteten, erschienen andere Linux-spezifische Virtualisierungslösungen wie KVM (Kernel Based Virtual Machine) und Lguest (anfangs Lhype). Die Kernel-Entwickler drängen daraufhin auf eine Schnittstelle, damit der Linux-Kernel als paravirtualisierter Gast unter all diesen und anderen Virtualisierungslösungen möglichst gut arbeitet, ohne für jeden der Hypervisor größere Mengen an speziellem Code in den Kernel mitzubringen. Maßgeblich unter der Leitung des Lguest-Entwickler entstand daraufhin die paravirt_ops genannte Abstraktionsschicht, die mit Linux 2.6.20 den Weg in den Hauptentwicklungszweig von Linux fand.

Mit eben dieser Version nahmen die Entwickler aber auch die Virtualisierungslösung KVM in Linux auf. Die war zu der Zeit erst wenige Monate alt, fügte sich aber deutlich besser als die Xen-Unterstützung in den Kernel ein und stellte nach Ansicht mancher Kernel-Hacker die technisch deutlich elegantere Lösung dar, da sie den Kernel selbst zum Hypervisor macht und dabei auf die Infrastruktur des Kernels (Scheduler, Speicherverwaltung, Treiber) zurückgreift, während bei der Xen-Hypervisor dem Linux-Kernel vorgeschaltet ist.

KVM erfordert allerdings für seine Arbeit CPUs mit Virtualisierungsfunktionen wie AMD-V oder Intel VT. Xen kann diese Funktionen ebenfalls nutzen, um unmodifizierte Gastsysteme zu virtualisieren. An Xen angepasste Betriebssysteme laufen unter dem Xen-Hypervisor allerdings mit Hilfe von Paravirtualisierung auch als Gast, wenn die CPU keine solchen Funktionen bietet. Diesen Unterschied führt Fitzhardinge jetzt als einen der Vorteile von Xen an – alle neueren x86-Server-Prozessoren sowie viele Desktop- und Notebooks-CPUs bieten heute allerdings Virtualisierungsfunktionen.

Zweiter Anlauf bei XEN, SSDs und Dateisysteme

Zweiter Anlauf

Während sich KVM im Rahmen der normalen Kernel-Entwicklung stetig und mit hoher Geschwindigkeit weiterentwickelte und Funktionen wie Migration oder das Durchreichen von PCI-Geräten an Gäste lernte, trieben die Xen-Entwickler die Integration von Xen in den Linux-Kernel nur mehr langsam voran. Vielmehr steckten sie viel Arbeit in die Weiterentwicklung des auch in kommerziellen Xen-Produkten genutzten Xen-Codes, der auf den Linux-Kernel 2.6.18 aufsetzt und den Qualitätsansprüchen der Kernel-Entwickler nicht genügt. 2.6.18 fehlen allerdings viele Treiber für neuere PC-Komponenten. Die Entwickler der Distributoren portierten daher diesen Xen-Code auf neuere Kernel. Das war und ist überaus aufwendig und das Ergebnis funktioniert in der Praxis manchmal mehr schlecht als recht; das dürfte einer der Gründe sein, der Red Hat zum Kauf des auf KVM spezialisierten Unternehmens Qumranet bewegt hat, was wiederum die kürzliche bekannt gewordene Pläne zum Einsatz von KVM in verschiedenen Red-Hat-Produkten nach sich gezogen hat.

Parallel zur Weiterentwicklung des "alten" Xen-Codes arbeiteten Fitzhardinge und andere an Xen-Patches, die sich besser in den Kernel einfügen und paravirt_ops verstärkt nutzen. Zuerst entwickelten sie dazu den Code für Xen-Gastsysteme (DomU), den die Kernel-Entwickler bei der Linux-Version 2.6.23 integrierten – dieser Code ist in den Standard-Kernel vieler Distributionen aktiv, sodass sie daher heute auch problemlos als Gast-Kernel unter einem modernen Xen-Hypervisor arbeiten.

Der Xen-Hypervisor macht aber vieles nicht alleine, sondern arbeitet intensiv mit einem Dom0-Kernel zusammen. Die ließen sich bislang nur mit der alten Xen-Codebasis aufsetzen, den die Kernel-Entwickler aus Qualitätsgründen ablehnen. Dies Manko sollen die jetzt von Fitzhardinge veröffentlichten Patches zum Betrieb als Dom0-System beseitigen; wie er selbst schreibt, hat er dazu große Teile des Xen-Codes neu geschrieben. Die jetzigen Patches legen allerdings nur die Basis für die Dom0-Unterstützung und haben noch lange nicht den Funktionsumfang, den die ältere Xen-Codebasis bietet. Fitzhardinge plant daher weitere Patch-Serien. Bis diese fertig gestellt sind und bis die gröbsten Fehler in dem noch jungen oder noch gar nicht existierenden Code beseitigt sind, dürfte daher noch einige Zeit vergehen – so die Kernel-Entwickler die Dom0-Unterstützung denn überhaupt aufnehmen.

SSDs und Dateisysteme

Theodore Ts'o (kurz Ted Tso oder Tytso) bloggte in den vergangenen Tagen fleißig zu SSDs (Solid State Disks) und den von ihm betreuten Ext-Dateisystemen Ext2, Ext3 und Ext4. Den Anfang machte er mit "Should Filesystems Be Optimized for SSDs?". Er geht dabei detailliert auf die Funktionsweise von SSDs sowie deren Wear-Leveling-Funktionen ein, zu denen sich auch Torvalds jüngst in einem Webforum ausgelassen hatte, die Anlass für den Blog-Eintrag des Dateisystementwicklers war. Eine einfache Antwort auf die Frage, ob Dateisysteme für SSDs optimiert werden müssen, findet Ted Tso allerdings auch nicht, denn das hängt von der eingesetzten SSD sowie der weiteren Entwicklung der immer noch jungen und sich stetig wandelnden Datenträgertechnik ab.

In einem weiteren Blog-Eintrag beschäftigt er sich ausführlich damit, ob sich Ext2 tatsächlich besser für SSDs eignet als Ext3 oder Ext4, wie es einige Howtos sowie Blog- und Foren-Einträge erklären. Er macht dabei zahlreiche Tests und nutzt dabei auch die für Linux 2.6.29 aufgenommene und maßgeblich von Google-Entwicklern ausgearbeitete Unterstützung zum Betrieb von Ext4 ohne Journal. Bei seinen Test zeigen sich Unterschiede zwischen verschiedenen Dateisystemen und den verschiedenen Mountoptionen wie "noatime" und "relatime", wobei der Effekt von "noatime" deutlich größer ist als die Wahl des Dateisystems.

Wer sich weiter mit Dateisystemen auseinander setzen will, findet in Teds Blog-Eintrag "Fast ext4 fsck times, revisited" noch mehr Stoff; darunter auch Angaben zu den fsck-Prüfungszeiten mit verschiedenen Codepfaden zum Anordnen von Daten im Dateisystem/auf dem Datenträger. Christoph Hellwig gab derweil in einer Mail einen Überblick über jüngst umgesetzte oder für die nahe Zukunft geplante Änderungen rund um XFS. Und wem das immer noch nicht genug ist: Während die Entwickler des Dateisystems btrfs fleißig an Performance-Optimierungen werkeln, arbeitet Daniel Phillips stetig weiter an Tux3 und hält die Allgemeinheit mit Informationsschnipseln bei Laune; kürzlich stellte er etwa das PDF einer auf der SCALE 7x gehaltenen Präsentation online, die Details zur Funktionsweise des Tux3-Dateisystems erläutert.

Neue stabile Kernel, Kernel-Log-Staccato

Kernel-Status

Nachdem die Betreuer der Stable-Kernel-Series in den ersten drei Februarwochen zahlreiche neuer Stable-Kernel veröffentlichten, ging es in den vergangenen Tagen wieder etwas gemächlicher zu, sodass die im vorangegangenen Kernel-Log bereits angedeuteten und wenig später erschienenen Versionen 2.6.27.19 und 2.6.28.7 fürs erste aktuell bleiben.

Die 2.6.29-Entwicklung ist derweil beim rc7 angelangt. Torvalds deutete bei der Freigab an, dass vermutlich noch eine achte Vorabversion nötig sein wird, da die Liste der neu eingeschleppten Fehler (Regressions) noch recht lang sei; zirka eineinhalb oder zwei Wochen dürfte es daher wohl mindestens noch dauern, bis Linux 2.6.29 erscheint.

Kernel-Log-Staccato

Kernel

• J. R. Okajima hat einen zweiten Anlauf zur Aufnahme des Dateisystems Aufs2 (Advanced Multi Layered Unification Filesystem Version 2/Another Unionfs) in den Hauptentwicklungszweig von Linux gestartet. Daraus entstand eine kurze Diskussion, ob sich die Linux-Entwickler besser auf Aufs2 oder das ältere und bereits seit längerem eine Aufnahme in den Kernel anstrebende Unionfs konzentrieren sollten.

• Die Kernel-Entwickler arbeiten an Unterstützung für ATA-Datenträger mit 4 KByte großen Sektoren.

• Auch die Entwickler von Ksplice arbeiten verstärkt auf eine Aufnahme des Frameworks zum Ausbessern von Kernel-Fehlern zur Laufzeit in den offiziellen Kernel-Zweig hin; einige grundlegenden Patches sind sogar schon in den für 2.6.30 vorbereiteten Entwicklerzweigen.

• Ein kürzlich erschienener Artikel auf IBM Developerworks beschreibt detailliert die Funktionsweise von Linux-SCSI-Treibern.

X.org

• AMD-Entwickler Alex Deucher berichtet in seinem Blog von den Fortschritten bei der Treiber-Unterstützung des Grafikkerns in RS600-Mainboardchipsätzen (Radeon Xpress X1200/X1250 für Intel-CPUs) sowie neuem Code zur Unterstützung von EXA und Xv bei R6xx- und R7xx-GPUs (Radeon-2000-Serie und neuer).

• X.org-Entwickler Peter Hutterer beschreibt derweil in seinem Blog, wie man mit evdev 2.1 und Xinput 1.4 sowie dem kürzlich freigegebenen X-Server 1.6 Mausrad-Unterstützung emulieren kann.

• Unter den kürzlich von den X.org-Entwicklern freigegebenen Treiber-Paketen findet sich auch eine neue Version des Grafiktreibers für Intel-Grafikchipsätze, die zahlreiche wichtige Fehlerkorrekturen für die 2.6-Serie der Treiber mitbringt. Es hatten sich aber noch einige neue Fehler eingeschlichen, die die kürzlich veröffentlichte Version 2.6.3 korrigiert.

• AMD hat kürzlich die Version 9.2 des proprietären Linux-Grafiktreibers fglrx freigegeben.

Verschiedenes

• Das Hplip-Projekt hat die Version 3.9.2 der Hplip-Treiber für Drucker und Multifunktionsgeräte von HP zum Download veröffentlicht. Sie erweitern die Liste der unterstützten Drucker um drei LaserJets, fünf Officejets und einen Photosmart.

• Mark Lord hat die Version 9.12 von hdparm freigegeben.

• Die Entwickler des LM-Sensors-Projekts haben die Version 3.1.0 des Frameworks zum Ansteuern von Hardware-Monitoring-Chips veröffentlicht. Es enthält ein komplett neues Script sensors-detect zum Einrichten von LM-Sensors.

Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich auch in den vorangegangen Ausgaben des Kernel-Logs auf heise open:

• 20.02.2009: Entwicklungstempo der Stable-Series steigt, X-Server 1.6 in Kürze
• 30.01.2009: Was 2.6.29 bringt (3): ACPI, PCI, PM – Verbesserungen für Notebooks und Stromsparmechanismen
• 27.01.2009: Neue Stable-Kernel, AMD-3D-Dokumentation und Mesa 7.3 freigegeben

• 15.01.2009: Was 2.6.29 bringt (2): Grafik – Kernel verwaltet Bildschirmauflösung
• 12.01.2009: Heiße Entwicklungsphase von 2.6.29 beendet, neue X.org-Treiber
• 05.01.2009: Was 2.6.29 bringt (1): Netzwerk – "Mistige" WLAN-Treiber, Wimax- und AP-Unterstützung

• 05.01.2009: 2.6.29-Entwicklung angelaufen, Neues bei 3D-Unterstützung
• 25.12.2008: Linux-Kernel 2.6.28 erschienen; Höher und weiter - Die Neuerungen von Linux 2.6.28
• 19.12.2008: Was 2.6.28 bringt (9) – Fastboot und andere Überbleibsel

Ältere Kernel-Logs finden sich über das Archiv oder die Suchfunktion von heise open. (thl/c't) (thl)