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.
- Thorsten Leemhuis
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.
Neuzugänge
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.
Tuning
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.
Die kleinen Perlen
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
- Btrfs: add a "df" ioctl for btrfs
- Btrfs: add ioctl and incompat flag to set the default mount subvol
- Btrfs: add search and inode lookup ioctls
- Btrfs: cache the extent state everywhere we possibly can V2
- Btrfs: kill max_extent mount option
- Btrfs: make df be a little bit more understandable
- Btrfs: make subvolid=0 mount the original default root Btrfs: run the backing dev more often in the submit_bio helper
Ext-Familie
- ext4: Add new tracepoint for jbd2_cleanup_journal_tail
- ext4: Add new tracepoints to debug delayed allocation space functions
- ext4: deprecate obsoleted mount options
Weitere:
- 9P2010.L handshake: Add mount option
- 9p: documentation update
- add several pieces to shared subtree documentation
- CIFS: Add mmap for direct, nobrl cifs mount types
- doc: add the documentation for mpol=local
- Documentation/fs/: split txt and source files
- exofs: Define on-disk per-inode optional layout attribute
- exofs: groups support
- fs/9p: Add hardlink support to .u extension
- FS-Cache: Remove the EXPERIMENTAL flag
- net/9p: Add multi channel support.
- nfsd: 4.1 has an rfc number
- ocfs2_dlmfs: Add capabilities parameter.
- ocfs2/userdlm: Add tracing in userdlm
- quota: split out compat_sys_quotactl support from quota.c
- reiserfs: properly honor read-only devices
- Remove EXPERIMENTAL from NFS_FSCACHE
- Squashfs: add a decompressor framework
- Squashfs: add decompressor entries for lzma and lzo
- xfs: Add trace points for per-ag refcount debugging.
- xfs: add tracing to xfs_swap_extents
- xfs: implement optimized fdatasync
- xfs: Non-blocking inode locking in IO completion xfs: Use delayed write for inodes rather than async V2
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)