Kernel-Log – Was 2.6.34 bringt (2): Dateisysteme

Der Linux-Kernel wird mit der Version 2.6.34 erstmals die Dateisysteme Ceph und LogFS unterstützten. Einige Änderungen am Btrfs- und XFS-Code versprechen bessere Performance. Ausserdem soll der Kernel soll nun besser mit Platten umgehen können, die mit 4 KByte großen logischen Sektoren arbeiten.

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

Dienstag früh hat Linus Torvalds die fünfte Vorabversion von Linux 2.6.34 veröffentlicht. In der Freigabe-Mail hebt Torvalds unter anderem eine Korrektur für ein Problem im ACPI-Subsystem hervor, das mehrere Tester geplagt hatte.

Nach den Anlaufschwierigkeiten zu Beginn der 2.6.34-Entwicklung erschien der RC5 – wie in dieser Phase des Entwicklungszyklus üblich – ungefähr eine Woche nach dem RC4. Den hatte Torvalds ungewöhnlich spät veröffentlicht, denn er und einige andere Entwickler hatten zuvor tagelang einem Fehler in Memory-Management-Code des Kernels nachgespürt. Dabei entstanden neben einer sehr langen Diskussion auch Korrekturen für einige andere bei der Suche entdeckte Fehler. Details zu den Vorgängen und einen tiefen Einblick in einen Teil des Virtual-Memory-Subsystems liefert der Artikel "The case of the overly anonymous anon_vma" bei LWN.net.

Nach dem ersten, den Änderungen im Netzwerk-Bereich gewidmeten Teil der Mini-Serie "Was 2.6.34 bringt" beschäftigt sich dieses Kernel-Log mit den Neuerungen rund um Dateisysteme; folgen werden in den kommenden Wochen noch Artikel zur Grafik-Unterstützung, zum Architektur-Code, zu Treibern und einigen weiteren Funktionsbereichen.

Die Zahl der vom Linux-Kernel unterstützen Dateisysteme hat sich durch die Aufnahme von Ceph und LogFS abermals erhöht.

Bei Ceph (Git-Pull-Request) handelt es sich um ein experimentelles und unter der LGPL lizenziertes "Distributed Network File System" – also ein verteiltes, replizierendes Netzwerkdateisystem für Cluster. Es soll sich laut Beschreibung der Entwickler zur Verwaltung von Datenmengen im Petabyte-Bereich "und darüber hinaus" eignen, bereits robust arbeiten und zahlreiche Funktionen bieten, "die vergleichbaren Open-Source-Dateisystemen fehlen".

Dazu gehört die Möglichkeit, das Dateisystem einfach durch Hinzustecken weiterer Server zu erweitern, wobei Ceph die Daten automatisch auf die neuen Server verteilt; zudem versucht das Dateisystem durch eine automatische Umverteilung der Daten den Datendurchsatz zu steigern. Zum Speichern der Daten verwendet es Teile des ebenfalls noch experimentellen Btrfs-Dateisystem-Codes; dennoch soll das als Forschungsprojekt am Storage Systems Research Center der Universität von Santa Cruz entstandene Dateisystem bereits benutzbar sein. Die Entwickler empfehlen bei wichtigen Daten allerdings dringend ein Backup.

Einen guten Überblick über Ceph bietet der beim amerikanischen Linux Magazine erschienene Artikel "Ceph: The Distributed File System Creature from the Object Lagoon" des auf HPC (High-performance computing) spezialisierten Dell-Mitarbeiters Jeffrey B. Layton. Weitere Informationen zu Ceph liefern die Kurzbeschreibung zu Ceph, die zusammen mit dem über mehr als 200 Commits verteilten Dateisystemcode integriert wurde, sowie ein älterer Artikel bei LWN.net, der eine frühere, noch auf Fuse aufsetzende Variante des Dateisystems beschreibt.

Auch mit dem zweiten neuen Dateisystem dürften die meisten Anwender zumindest auf absehbare Zeit eher selten direkt in Berührung kommen, denn LogFS ist ein mit Log-Strukturen arbeitendes Dateisystem, das primär für die im Embedded-Bereich eingesetzte Flash-Medien ohne Wear Levelling interessant ist. Grob gesprochen erledigt das maßgeblich vom deutschen Entwickler Jörn Engel entwickelte Dateisystem genau jene Dinge, um die sich bei SSDs (Solid-State Disks) mit SATA-Anschluss die Firmware kümmert – weshalb LogFS für Desktop-SSDs nicht interessant ist, denn dort dürften sich der Flash Translation Layer (FTL) und das Dateisystem zumeist in die Quere kommen. Einige Hintergründe zu LogFS liefern ein von 2007 stammender LWN.net-Artikel und die Dokumentation zu LogFS in den Kernel-Quellen.

Btrfs-Maintainer Chris Mason hat einige der wichtigsten und erst nach Ende des Merge Window in den Hauptentwicklungszweig eingepflegten Änderungen an Btrfs in seinen Git-Pull-Request kurz erläutert. So lässt sich in Zukunft festlegen, welches Subvolume standardmäßig eingebunden wird, wenn keines explizit angegeben wurde. Das soll für Distributionen interessant sein, die vor dem Einspielen von Updates einen Btrfs-Snapshot erzeugen, damit Anwender bei Problemen auf einen älteren Stand zurück wechseln können – an solch einer Funktion arbeiten einige Red-Hat-Entwickler für Fedora 13.

Eine Überarbeitung am Defrag-Code von Btrfs soll nicht nur Fehler beseitigen, sondern auch das Komprimieren ausgewählter Dateien auf sonst nicht mit Kompression arbeitenden Volumes ermöglichen; zudem können nun auch Teilbereiche einer Datei defragmentiert werden. Ferner gab es Optimierungen, durch die aktualisierte Dateien schneller zu finden sein sollen.

Nicht gefallen haben Torvalds einige für SquashFS eingereichte Verbesserungen, die das für unter anderem bei Live-CDs verwendete Dateisystem um Unterstützung für die Kompression mit LZMA erweitern. Der Autor will den Code jetzt überarbeiten, wird dazu jedoch einige Zeit brauchen. Einige Funktionen, die die Basis für LZMA- und LZO-Kompression legen, sowie einige andere Änderungen an SquashFS fanden dennoch den Weg in den Hauptentwicklungszweig.

Verschiedene Optimierungen am XFS-Code sollen den Datendurchsatz bei manchen Aufgaben steigern – Details zu diesen und anderen Änderungen am XFS-Code liefern die "XFS status updates" für Februar und März. Das bei 2.6.30 integrierte und für OSDs (Object-Based Storage Devices) gedachte Exofs (Extended Object File System) unterstützt nun RAID 0; RAID 5 und 6 seien in Planung.

Das Dateisystem nilfs2 kann nun Discard-Kommandos absetzen und so etwa SSDs über freigegeben Bereiche informieren. Durch eine Änderung am Paritionierungs-Code soll der Linux-Kernel auch mit Festplatten umgehen können, die nicht nur physisch, sondern auch logisch 4-KByte große Sektoren nutzen. Solche will Western Digital laut Commit-Kommentar und einer vorangegangenen Diskussion auf der LKML bald einführen, um damit die Begrenzung auf maximal 2 Terabyte große Partitionen bei der Festplatten-Einteilung mit MBR zu umschiffen.

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 Kernel-Quellen auf Kernel.org. Im Webfrontend liefern normalerweise der Commit-Kommentar und der Patch selbst zahlreiche weitere Informationen zur jeweiligen Änderungen.

Btrfs

Ext-Familie

Weitere:

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)