Newsletter heise-Bot heise-Bot Push Nachrichten Push Push-Nachrichten

Kernel-Log – Was 2.6.29 bringt (4): Dateisysteme, Storage – Btrfs, SquashFS, Ext4 ohne Journal und neue Storage-Treiber

Die Kernel-Entwickler haben mit Btrfs und SquashFS nicht nur zwei neue Dateisysteme aufgenommen, sondern auch Ext4, OCFS2 und XFS verbessert. Größere Änderungen gab es auch in den IDE-, Libata- und SCSI-Subsystemen sowie im Block-Layer.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 18 Min.
c't Magazin
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

Wenn man den von Linus Torvalds bei der Freigabe der siebten Vorabversion von 2.6.29 getätigten Aussagen glauben schenken darf, wird es noch etwa ein bis zwei Wochen dauern, bis der Linux-Kernel 2.6.29 erscheint. Das Kernel-Log will daher die Berichterstattung über die für 2.6.29 vorgesehenen Neuerungen an dieser Stelle mit einer Beschreibung der Neuerungen rund um Dateisysteme und Storage-Techniken fortsetzen.

Butter-Dateisystem

Wie bereits während des Merge-Window von 2.6.29 kurz berichtet, haben die Kernel-Entwickler das experimentelle Dateisystem Btrfs aufgenommen. Fertig ist es aber bei weitem noch nicht – vielmehr wollen die Kernel-Hacker es im Rahmen des Linux-Kernels weiter entwickeln und reifen lassen, ähnlich wie es bei Ext4 der Fall war, das im Herbst 2006 für Linux 2.6.19 aufgenommen wurde und kürzlich mit Linux 2.6.28 seine Hauptentwicklungsphase beendete.

Btrfs – kurz für B-tree FS, im Englischen gemeinhin aber als Butter FS ausgesprochen – ist ein "Copy On Write"-Dateisystem, das der bei Oracle angestellte Kernel-Entwickler Chris Mason aus der Taufe gehoben hat. Nach der ersten Ankündigung von Btrfs auf der Linux-Kernel Mailing List (LKML) im Juli 2007 fand der früher bei Suse lange für ReiserFS zuständige Entwickler schnell Unterstützung durch zahlreiche andere Entwickler – in den Commit-Kommentaren finden sich die Autor-Auszeichnungen von bei HP, Intel, Novell/Suse und Red Hat beschäftigten Entwicklern.

Bereits im Herbst 2007 haben sich einige wichtige Linux-Dateisystem-Entwickler bei einem Treffen auf Btrfs als "Next Generation Filesystem for Linux" geeinigt, wie Ext[234]-Dateisystementwickler Theodore Ts'o (kurz Ted Tso oder Tytso) vor einigen Monaten in einer Mail verriet. Die Ext4-Entwicklung treiben er und anderen dennoch voran, da dies durch die erprobte Ext3-Basis und die weiter fortgeschrittene Entwicklung als Übergangslösung gebraucht würde, bis Btrfs so weit gereift sei, dass ihm auch Unternehmenskunden vertrauen.

Das Btrfs-Wiki liefert einen Überblick über die wichtigsten Eigenschaften des von Grund auf neuen und speziell für Linux entwickelten Dateisystems:

  • Extent-basierte Datenspeicherung (maximale Dateigröße: 2^64 Byte)
  • Im Hinblick auf den Speicherverbrauch effiziente Speicherung von kleinen Dateien und Verzeichniseinträgen
  • Dynamische Zuteilung von Inodes
  • Schreibbare Snapshots
  • Subvolumes
  • Checksummen für Daten und Metadaten
  • Kompression
  • eingebaute Funktionen zum Zusammenfassen mehrerer Datenträger zu einem Volume mit verschiedenen RAID-Algorithmen
  • Dateisystem-Check und Defragmentierung zur Laufzeit
  • Schnelle Dateisystem-Checks
  • Effiziente inkrementelle Backups und Dateisystem-Mirroring
  • zuschaltbare Optimierungen für SSDs

Die Development Timeline erläutert einige Dinge, die noch auf der ToDo-List stehen, während das Changelog einen guten Überblick darüber liefert, was die Entwickler alles schon erreicht haben. Aufbau und Funktionsweise des Dateisystem erläutert ein anderes Wiki-Dokument, häufige Fragen beantwortet die FAQ. Während sich das Format der auf dem Datenträger gespeicherten Datenstrukturen im Verlauf der Entwicklungsphase von Ext4 gelegentlich änderte und so beim Umstieg auf neuere Kernel ein Umformatieren nötig machte, planen die Btrfs-Entwickler den Anwendern diese Umstände von nun an zu ersparen – vollkommen auszuschließen sind weitere Änderungen am Ondisk-Format von Btrfs allerdings nicht.

Btrfs wurde mit seiner kompletten Entwicklungshistorie aufgenommen, was sich auf insgesamt über 900 kleinere oder größere Commits im Quellcodeverwaltungssystem von Linux addiert hat. Nach der Aufnahme von Btrfs Anfang des Jahres Anfang Januar erweiterten die Kernel-Hacker das Dateisystem indes noch um neue Funktionen wie Unterstützung für SELinux. Weitere Änderungen für 2.6.30 finden sich bereits in Vorbereitung – einige von ihnen sollen die Performance weiter verbessern.

Während einige Linux-Distributionen jetzt erwägen, Ext4-als Standard-Dateisystem einzusetzen, wird selbiges bei Btrfs wohl noch eine Zeit lang dauern. Die Fedora-Entwickler haben Installer und Kernel in ihren Entwicklerzweig aber bereits um Btrfs-Unterstützung erweitert.

Kernel-Log – Was 2.6.29 bringt (4): Dateisysteme, Storage – Btrfs, SquashFS, Ext4 ohne Journal und neue Storage-Treiber

Kürbis-Dateisystem

Während die Aufnahme des experimentellen Btrfs sich erstmal nicht auf die meisten Anwender und Distributions-Entwickler auswirkt, dürfte die Integration von SquashFS schneller Auswirkungen zeigen. Bei ihm handelt es sich um ein komprimierten Read-Only-Dateisystem, das diversen Linux-Distributionen schon lange auf ihren von USB, CD oder DVD gestarteten Installation- oder Live-Medien einsetzen, um möglichst wenig Platz zu verbrauchen; auch im Embedded-Bereich kommt die Cramfs-Alternative daher häufig zum Einsatz. Die Kernel-Dokumentation zu Squashfs erläutert die Unterschiede zwischen Cramfs und Squashfs sowie die Funktionsweise des neuen Dateisystems detailliert.

In den vergangenen Jahren hatten die SquashFS-Entwickler sich bereits mehrfach um eine Aufnahme in den Linux-Kernel bemüht, waren aber an den Qualitätsansprüchen der Kernel-Hacker gescheitert. Die kritisierten Code-Abschnitte hatten die SquashFS-Entwickler bei der jetzt aufgenommenen Version 4.0 zu verbessern versucht. Die Aufnahme kam aber doch recht überraschend – nach längerer Diskussion um das für und wider sowie einige Probleme am aktuellen Code sagte Torvalds, dass es sinnlos wäre, es nicht aufzunehmen, wenn ohnehin alle Welt das Dateisystem benutzen würde ("if this is really in use by everybody, then not merging it is kind of pointless. "); wenig später integrierte er schließlich die SquashFS-Patches in den Hauptentwicklungszweig.

Noch mehr Dateisysteme

Auch bei den schon länger im Kernel enthaltenen Dateisystemen gab es einiges an Änderungen. So beherrscht der Kernel nun ein vorübergehendes Einfrieren von Dateisystemen (Filesystem Freeze; 1, 2, 3, LWN-Artikel) – das ist etwa für Container-Virtualisierung sowie für Backup-Lösungen interessant. eCryptfs beherrscht nun das Verschlüsseln von Dateinamen (u. .a. 1, 2, 3, 4); in XFS hingegen gab es zahlreiche größere Änderungen am Btree-Algorithmus (siehe Anhang). Größere Änderungen gab es auch beim Cluster-Dateisystem OCFS2, das nun ACLs, Security Attributes, Quotas und Metadata Checksummen unterstützt.

Zahlreiche kleine Verbesserungen, Aufräumarbeiten und Korrekturen gab es auch am Ext4 Dateisystem – einige von ihnen fanden zwischenzeitlich sogar den Weg in die Stable-Kernel der Serien 2.6.27 und 2.6.28. Die Ext4-Entwickler passten zudem die Dokumentation zum Aktivieren von Write-Barriern an, um die es kürzlich eine längere Diskussionen gegeben hatte (siehe auch LWN-Artikel zum Thema). Einige Änderungen am Fsync-Algorithmus sollen ferner die Performance ein wenig verbessern.

Wer will, kann dank einiger von Google-Entwicklern eingebrachten Änderungen nun Ext4-Dateisysteme ohne Journal betreiben und so die Geschwindigkeit nochmal steigern – bisher setzten mache Anwender noch auf Ext2, um den vom Journaling verursachten Overhead zu umgehen. Einige Messungen zum Einfluss von Journaling auf die performance sowie Überlegungen zum Einsatz von Ext-Dateisystemen auf SSDs finden sich in einem kürzlich veröffentlichten Blog-Eintrag von Theodore Ts'o. Wer sich näher für Ext4 interessiert, findet zudem zahlreiche Hintergrundinfos in einem kürzlich veröffentlichten IBM-Developerworks-Artikel.

Die Unterstützung für Defragmentieren zur Laufzeit ("Online Defrag") in Ext4 nahmen die Kernel-Entwickler noch nicht für 2.6.29 auf; Ende Januar wurde eine neue Varianten veröffentlicht, bei der einige zuvor kritisierte Codebereiche überarbeitet wurden (siehe auch LWN-Artikel zum Thema).

Qual der Wahl bei IDE/PATA

Auch in diesem Entwicklungszyklus gab es wieder zahlreiche Änderungen am IDE-Subsystem des Kernels, das vorwiegend Parallel-ATA-Adapter (gemeinhin als "IDE-Adapter" bezeichnet) ansteuert (1, 2 3). So portierte der für diesen Kernel-Bereich zuständige Entwickler Bartlomiej Zolnierkiewicz einen Libata-Treiber für den CS5536 auf das IDE-Subsysteme und nahm den bei 2.6.18 entfernten Treiber IT8172 für den gleichnamigen Chip von ITE wieder auf. Auch an einigen grundlegenden Kernel-Funktionen gab es einige größere Änderungen (siehe Anhang).

Für viele Anwender dürfte diese Änderungen das aber keine größere Bedeutung haben, denn die meisten aktuellen Linux-Distributionen nutzen zur Ansteuerung von Parallel- und Serial-ATA-Adaptern schon seit längerem vorwiegend die Treiber des Libata-Subsystems. Die mit 2.6.19 aufgenommene PATA-Treiber auf Libata-Basis dürften dadurch wohl mittlerweile deutlich besser getestet sein als die eigentlich älteren Treiber des sich in den letzten Monaten stetig wandelnden IDE-Subsystems. Wie lange die Kernel-Entwickler diese zwei Treiber-Arten weiter pflegen wollen, ist ungewiss. Ursprünglich war erwartet worden, dass das alte IDE-Subsystem entfernt wird, nachdem sich die Libata-PATA-Treiber etabliert haben; derzeit sieht es aber nicht so aus, als ob das bald passieren würde.

Libata und SCSI, Anhang

Libata, SCSI und Unterbau

Die Libata-Entwickler waren derweil auch keineswegs untätig (1, 2). So erweiterte Alan Cox das Libata-Subsystem um 32-Bit-PIO-Unterstützung; der sata-sil-Treiber hingegen beherrscht nun Large Block Transfers. Neu dabei ist die Unterstützung für die VIA-Chips VT6415 (PATA), VT8261 (SATA) sowie den den VX855 (PATA) sowie dessen Verwandten mit der PCI-ID 0x0571.

Wie angekündigt haben die Kernel-Hacker den zum SCSI-Subsystem gehörenden Treiber ide-scsi entfernt, da 2.6er-Kernel und moderne Brennprogramme schon lange dazu in der Lage sind, ohne SCSI-Emulation auf IDE-CD/DVD-Brenner zuzugreifen. Neu im SCSI-Subsystem ist die maßgeblich von Intel im Rahmen des Open-FCoE-Projekts entwickelte Libfc – eine modulare Fibre Channel Library, auf die die ebenfalls neu aufgenommene Unterstützung für Fibre Channel over Ethernet zurückgreift. Erstmals dabei ist auch der iSCSI-Treiber cxgb3i für Chelsio-Adapters mit T3-Chips.

Über das Pseudo-Dateisystem Sysfs kann man dem IDE-, Libata- und SCSI-Subsystemen zugrundeliegende Block-Layer nun mitteilen, ob es sich bei einem Datenträger um ein "rotierendes Medium" handelt, sofern der Kernel das nicht selbst feststellen kann. Andere Kernel-Subsysteme und Userspace-Programme können mit Hilfe dieser Informationen für Festplatten oder SSDs ideale Zugriffsmuster aktivieren, um die bestmögliche Geschwindigkeit beim Schreiben und Lesen von Daten zu erzielen. Der Device Mapper (DM) unterstützt nun Barrier und stellt so auf Wunsch des Dateisystems sicher, dass Daten wirklich auf die am DM-Verbund beteiligten Datenträger geschrieben wurden, bevor die nächsten Aufgaben angegangen werden – das ist für die Integrität von Dateisystemen mit Journal von Vorteil (siehe auch LWN-Artikel zum Thema).

Neben den bereits erwähnten Neuerungen gab es für 2.6.29 noch zahlreiche weitere wichtige Änderungen rund um Dateisysteme und die Storage-Unterstützung des Linux-Kernels:

Dateisysteme

Btrfs

  • zu viele Commits, um sie hier alle aufzulisten; eine Übersicht bieten die Git-Pull-Requests (1, 2, 3, 4, 5, 6) sowie das Git-Web-Interface auf kernel.org.

CIFS

Ext[234]

Fuse

OCFS2

SquashFS

UBIFS

XFS

VFS, andere Dateisysteme

Storage

DM, DMA, MD, UBI sowie Block-Layer inklusive IO-Scheduler

IDE

Libata

MMC

MDT

SCSI

(thl/c't) (thl)

Spiele

nach oben
Alle Angebote
Newsletter heise-Bot heise-Bot Push Nachrichten Push Push-Nachrichten