Seite 2: Zweiter Anlauf bei XEN, SSDs und Dateisysteme

Inhaltsverzeichnis

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.