Kernel-Log – Was 2.6.30 bringt (2): Neue und überarbeitete Dateisysteme
Zahlreiche Änderungen beeinflussen Datensicherheit und die Performance von Ext3 und Ext4. Neu dabei sind Exofs und Nilfs2 sowie der FS-Cache für AFS und NFS. Korrekturen gab es am kaum mehr betreuten Reiserfs.
- Thorsten Leemhuis
Mitte der Woche hat Linus Torvalds die dritte Vorabversion von Linux 2.6.30 freigegeben. Sie bringt abgesehen von zwei Code-Umstrukturierungen vorwiegend kleinere Verbesserungen und Korrekturen, wie es in der zweiten Phase des Entwicklungszyklus üblich ist.
Mittlerweile sind auch die langwierigen Diskussionen rund um Dateisysteme Ext3 und Ext4 sowie deren Interaktion mit anderen Kernel-Subsystemen weitgehend zur Ruhe gekommen. Über deren Anfänge hatte heise open berichtet – die gelegentlich etwas ruppige Diskussion auf der LKML ging danach jedoch noch mehr als eine Woche emsig weiter. So kamen schließlich 650 Mails zusammen – andere, durch diese Diskussion aufgelöste Threads nicht mitgezählt.
Die Debatten waren jedoch keineswegs fruchtlos, sondern führten zur Entwicklung einiger Änderungen, die Torvalds teilweise sofort in den derzeit zu Linux 2.6.30 führenden Hauptentwicklungszweig integrierte. Über diese sowie zahlreiche andere Änderungen rund um den Code der verschiedenen von Linux unterstützten Dateisysteme gibt der folgende zweite Teil der Kernel-Log-Mini-Serie "Was 2.6.30 bringt" gibt einen Überblick.
Zugriffszeit
Relativ früh kochte in der erwähnten Diskussion ein altes, schon häufig diskutiertes und Dateisystem-übergreifendes Thema erneut hoch: Wann beziehungsweise wie häufig soll der Kernel die Zugriffszeit (Atime/Access Time) einer Datei aktualisieren? Die Information ist nur für eine Handvoll Anwendungen von Bedeutung, jede Aktualisierung zieht jedoch einen Schreibvorgang nach sich – die kosten nicht nur Zeit, sondern sind gerade bei SSDs oder mit Akku laufenden Notebooks eher unerwünscht.
Matthew Garrett erstellte daraufhin einige Patches, durch die der Kernel die Zugriffszeit nur mehr einmal pro Tag aktualisiert (Relative atime/relatime). Linus Torvalds nahm diese Änderungen nur wenige Stunden später als eine der ersten nach der Freigabe von 2.6.29 in den Hauptentwicklungszweig auf. Ein weiterer Patch von Garrett machte relatime zum Standard; das alte Verhalten lässt sich mittels strictatime aktivieren.
Doch auch diesen von vielen Kernel-Hackern schon lange geforderten Änderungen stellen nicht alle Entwickler zufrieden – Valerie Aurora (vormals Henson) nennt einige Kritikpunkte in ihrem Blog. Es ist daher nicht auszuschließen, dass das Thema früher oder später erneut aufs Tapet kommt.
Wartezeiten und Datensicherheit bei Ext3/4
Wartezeit
Ausgelöst hatte die Diskussion auf der LKML ein Nutzer, der von langen Wartezeiten bei Anwendungen berichtete, sobald diese mittels fsync() ein Leeren der Ext3-Schreibpuffer auslösen, während der Kernel parallel größere Leseanforderungen abarbeitete. Dieses Problem ist seit Monaten bekannt, die erhältlichen Workarounds waren allerdings umstritten.
Ext[234]-Dateisystementwickler Ted Ts'o kritisiert in dem Rahmen die Anwendungsentwickler, die durch umsichtigeres Vorgehen dem Dateisystem einiges an Arbeit ersparen könnten; andere Kernel-Hacker sind da jedoch ganz anderer Meinung. Ted Ts'o hatte jedoch bereits einige weniger kontroverse und später für 2.6.30 aufgenommene Patches für Ext3 und Ext4 entwickelt, die die Wartezeiten laut seinen Messungen verkürzen.
Im Rahmen von Tests fand Torvalds später jedoch heraus, dass auch der CFQ-Scheduler des Block-Layers eine Mitschuld an den Wartezeiten trägt. Jens Axboe analysierte das Problem und erarbeitete kurzfristig weitere Änderungen, die die Wartezeiten weiter reduzieren. Das dürfte im Einzelfällen die Geschwindigkeit von Desktop-Systemen nicht nur messbar, sondern sogar spürbar steigern.
Wartezeit, die zweite
Debatten und Details
Der nebenstehende Text erwähnt nur die allerwichtigsten Punkte sowie Resultate der eingangs erwähnten Diskussionen rund um Ext3 und Ext4 sowie deren Interaktion mit anderen Kernel-Subsystemen wie dem Block Layer. Linux Weekly News (LWN.net) hat sich in den Artikeln That massive filesystem thread und Solving the ext3 latency problem detaillierter mit den Diskussionen und den daraus hervorgegangenen Änderungen beschäftigt.
Auch die Artikel "Linux Storage and Filesystem workshop" Day 1 und Day 2 gehen an einigen Stellen auf die in angesprochenen Aspekte ein. Mit dem Problem potenziellen Datenverlusts bei Ext4 beschäftigt sich der Artikel ext4 and data loss.
Das eigentliche Problem für die Wartezeiten sei aber nicht unerheblich durch die Eigenschaft von Ext3 bedingt, Dateisysteme standardmäßig als "data=ordered" einzubinden; Ted Ts'o bereute sogar die vor Jahren getroffene Entscheidung, diesen Modus als Standard vorgegeben zu haben.
Nachdem es anfangs schien, als blieben diese Diskussionen fruchtlos, nahm Torvalds einige Tage später einige von Ted Ts'o entwickelte Patches auf. Darunter einer, durch den der Kernel Ext3-Dateisysteme mit "data=writeback" einbindet, sofern es der Anwender bei der Kernel-Konfiguration oder dem Mounten nicht explizit anders vorgibt. Das soll die Performance steigern, erhöht jedoch die Gefahr eines Datenverlustes beim Absturz oder außerplanmäßigen Ausschalten des PC; zudem besteht die Gefahr, dass sich in neuen, vor einem Absturz nicht komplett geschriebenen Dateien Daten von zuvor gelöschten Dateien finden, die möglicherweise einem anderen Nutzer gehörten.
Einige dieser Probleme soll der von Btrfs-Hauptentwickler Chris Mason entwickelte Modus "data=guarded" lösen. Zwei im Rahmen dieser Entwicklung programmierte Verbesserungen fanden bereits jetzt den Weg in den Hauptentwicklungszweig; der Rest wurde zurückgestellt, da sich der Entwicklungszyklus mittlerweile in der Stabilisierungsphase befand.
Datensicherheit
In dem Trubel der Diskussion kam auch die Anfang März bekannt gewordene Gefahr eines Datenverlusts durch Delayed Allocation von Ext4 erneut zur Sprache. Die sollen aber einige Patches für den Ext4-Code deutlich mindern, die wie geplant den Weg in den Hauptentwicklungszweig fanden – die Änderungen beeinflussen die Performance in machen Situationen allerdings negativ.
Die Diskussionen rund um das Datenverlustrisiko führten zu einer Debatte, welche Garantien Dateisysteme überhaupt liefern müssen; das führte wiederum zu der Frage, ob und wie Kernel und Dateisystem überhaupt sicherstellen sollen, dass die Daten nicht nur im Write-Cache eines Datenträgers landen, sondern auch tatsächlich in der richtigen Reihenfolge geschrieben werden. Über diese und andere Fragen rund um Performance-Tuning entstand dann eine Diskussion, welche Einstellungsvorgaben die Kernel-Entwickler machen sollen und wo sie das Feintuning besser den Linux-Distributoren überlassen.
Exofs, Nilfs2, FS-Cache, Btrfs und Reiserfs
Zwei neue
Nach der Aufnahme von Btrfs und SquashFS bei Linux 2.6.29 haben die Kernel-Entwickler für 2.6.30 mit Nilfs2 und EXOFS abermals zwei neue Dateisysteme integriert.
Bei Nilfs2 (New Implementation of a Log-structured Filesystem Version 2) handelt es sich um ein Log-structured File System (LFS) mit Continuous Snapshotting, das speziell für die Belange von Solid State Discs (SSD) optimiert ist. Eine detaillierte Beschreibung der Arbeitsweise liefern die Nilfs2-Homepage und die Kernel-Dokumentation zu Nilfs2; weitere Details finden sich bei einer im Februar im Rahmen des "Linux Storage & Filesystem Workshop 2008" (LSF'08) gehaltenen Präsentation, die auch einen Vergleich Nilfs2 mit btrfs, ext[2-4], reiserfs und XFS beim Betrieb mit einer SSD enthält. Zudem geht der schon etwas ältere Vortrag von Dongjun Shin auf einige Besonderheiten von Dateisystemen für SSDs näher ein.
Exofs steht für Extended Object File System und hieß zuvor Osdfs (Object-Based Storage Devices File System). Wie der alte Name andeutet, ist es für die eher exotischen OSDs (Object-Based Storage Devices) gedacht, die das SCSI-Subsystem mit dem Kernel 2.6.30 erstmals unterstützen wird. Wer sich für diese Speichertechnik und das Dateisystem näher interessiert, findet Details in dem Artikel von Sun zu OSDs, dem OSD Protocol, der Kernel-Dokumentation zu EXOFS, der Homepage der EXOFS-Entwickler und einem LWN.net-Artikel zu EXOFS/OSDFS.
Kernel-Log – Was 2.6.30 bringt
Weitere Teile aus der Kernel-Log-Mini-Serie "Was 2.6.29 bringt":
1. Netzwerk – Neue Treiber für LAN und WLAN
Der Artikel "Stetes Wachstum – Die Neuerungen von Linux 2.6.29" bietet eine Übersicht über die Neuerungen der bei der Artikel-Veröffentlichung aktuellen Kernel-Version der Hauptentwicklungslinie.
Das bei der Freigabe dieses Artikels neueste reguläre Kernel-Log beschäftigt sich verschiedenen Entwicklungen rund um die Linux-Grafiktreiber für GPUs von AMD und Intel; wie immer finden auch zahlreiche weitere Geschehnisse rund um den Linux-Kernel und andere Hardware-nahe Linux-Software kurz Erwähnung. Weitere Kernel-Logs finden sich über die Übersichtsseite von heise open.
Zwischenspeicher für Netz, Aufguss für Btrfs
Nach mehren Jahren Entwicklung haben die Kernel-Entwickler auch die maßgeblich von Red-Hat-Entwickler David Howells entwickelten FS-Cache-Patches aufgenommen (Kernel-Dokumentation). Durch die Erweiterungen lässt sich ein Dateisystem-Cache einrichten, um den Datenverkehr beim Einsatz von Netzwerk-Dateisystemen wie AFS oder NFS zu reduzieren; das ist etwa bei Thin Clients mit kleinen Festplatten oder Flash-Medien interessant, die ihr Root-Dateisystem und alle anderen Daten übers Netz beziehen.
Auch die Btrfs-Entwickler waren fleißig und optimierten den Dateisystemcode, sodass dieses mit 4k-Stacks besser zurecht kommt; weitere Verbesserungen in dieser Richtung stehen noch auf der ToDo-Liste. Darüber hinaus gab es einige Optimierungen, die die Schreib-Performance allgemein sowie beim SSD-Betrieb steigern sollen.
Reiserfs nicht ganz verlassen
Der ReiserFS-Code des Kernels gilt zwar noch als "supported", hat aber schon seit längerem keinen offiziellen Maintainer mehr, der den Code betreut – daher gab es am ihm in den vergangenen Monaten nur kleinere Änderungen, die sicherstellten, dass das früher populäre Dateisystem überhaupt weiter funktioniert.
Über Novell-Entwickler Jeff Mahoney fanden nun jedoch zahlreiche im Rahmen von SLED/SLES entwickelte und teilweise bereits über zwei Jahre alte Patches den Weg in den Hauptentwicklungszweig. Sie sollen Ungereimtheiten oder Fehler im auch Reiser3 genannten ReiserFS beseitigen. Beim Git-Pull-Request meinte Mahoney, dass sich ReiserFS nach Aufnahme dieser Patches im "tiefen Instandhaltungsmodus" (deep maintenance-only mode) befände. Im Rahmen der Diskussion um den Git-Pull-Requests ließ Frederic Weisbecker jedoch durchblicken, dass er an Änderungen arbeitet, die die Verwendung des Big Kernel Locks (BKL) in Reiserfs reduzieren sollen.
CIFS-DFS verbessert und andere kleine Perlen
Die kleineren Perlen
Die DFS-Unterstützung von CIFS erweiterten die Kernel-Entwickler um Unterstützung zum Erreichen entfernter Server.
Bei dieser und den anderen bisher genannten Neuerungen handelt es sich nur um die bedeutsamsten Änderungen, die die Kernel-Hacker am jüngst Code der verschiedene Dateisysteme vorgenommen haben. Zahlreiche weiterer wichtige Änderungen finden sich in der folgenden Liste mit den Überschriften des jeweiligen Commits im Hauptentwicklungszweigs; über die Links gelangt man direkt zur Änderungen im Webfrontend des Hauptentwicklungszweigs, wo der Commit-Kommentar und der Patch selbst weitere Informationen zu diesen vielleicht etwas weniger wichtigen, aber keineswegs unbedeutenden Änderungen vermitteln.
Filesystems:
Btrfs
- Btrfs: add a priority queue to the async thread helpers
- Btrfs: add extra flushing for renames and truncates
- Btrfs: add flushoncommit mount option
- Btrfs: do extent allocation and reference count updates in the background
- Btrfs: notreelog mount option
- Btrfs: Optimize locking in btrfs_next_leaf()
- Btrfs: rework allocation clustering
- Btrfs: stop spinning on mutex_trylock and let the adaptive code spin for us
- Btrfs: use WRITE_SYNC for synchronous writes
FS-Cache
- CacheFiles: A cache that backs onto a mounted filesystem
- CacheFiles: Export things for CacheFiles
- CacheFiles: Permit the page lock state to be monitored
- Create a dynamically sized pool of threads for doing very slow work items
- Document the slow work thread pool
- FS-Cache: Add and document asynchronous operation handling
- FS-Cache: Add cache management
- FS-Cache: Add cache tag handling
- FS-Cache: Add main configuration option, module entry points and debugging
- FS-Cache: Add netfs registration
- FS-Cache: Add the FS-Cache cache backend API and documentation
- FS-Cache: Add the FS-Cache netfs API and documentation
- FS-Cache: Add use of /proc and presentation of statistics
- FS-Cache: Bit waiting helpers
- FS-Cache: Implement data I/O part of netfs API
- FS-Cache: Implement the cookie management part of the netfs API
- FS-Cache: Make kAFS use FS-Cache
- FS-Cache: Object management state machine
- FS-Cache: Provide a slab for cookie allocation
- FS-Cache: Recruit a page flags for cache management
- FS-Cache: Release page->private after failed readahead
- FS-Cache: Root index definition
- Make slow-work thread pool actually dynamic
- Make the slow work pool configurable
- NFS: Add comment banners to some NFS functions
- NFS: Add FS-Cache option bit and debug bit
- NFS: Add mount options to enable local caching on NFS
- NFS: Add read context retention for FS-Cache to call back with
- NFS: Add some new I/O counters for FS-Cache doing things for NFS
- NFS: Define and create inode-level cache objects
- NFS: Define and create server-level objects
- NFS: Define and create superblock-level objects
- NFS: Display local caching state
- NFS: FS-Cache page management
- NFS: Invalidate FsCache page flags when cache removed
- NFS: nfs_readpage_async() needs to be accessible as a fallback for local caching
- NFS: Permit local filesystem caching to be enabled for NFS
- NFS: Read pages from FS-Cache into an NFS inode
- NFS: Register NFS for caching and retrieve the top-level index
- NFS: Store pages from an NFS inode into a local cache
- NFS: Use local disk inode cache
exofs
- exofs: address_space_operations
- exofs: dir_inode and directory operations
- exofs: Documentation
- exofs: export_operations
- exofs: file and file_inode operations
- exofs: Kbuild, Headers and osd utils
- exofs: super_operations and file_system_type
- exofs: symlink_inode and fast_symlink_inode operations
- fs: Add exofs to Kernel build
Ext[234]
- ext3: Add replace-on-rename hueristics for data=writeback mode
- ext3: Add replace-on-truncate hueristics for data=writeback mode
- ext3: Avoid starting a transaction in writepage when not necessary
- ext3: make default data ordering mode configurable
- ext3: Try to avoid starting a transaction in writepage for data=writepage
- ext4: add EXT4_IOC_ALLOC_DA_BLKS ioctl
- ext4: Add fine print for the 32000 subdirectory limit
- ext4: Add sysfs support
- ext4: Automatically allocate delay allocated blocks on close
- ext4: Automatically allocate delay allocated blocks on rename
- ext4: Fix discard of inode prealloc space with delayed allocation.
- ext4: Regularize mount options
- ext4: remove /proc tuning knobs
- ext4: Track lifetime disk writes
- trivial: document ext3 semantics of 'ro' option a bit better
Nilfs2
- Nilfs2: add document
- Nilfs2: add inode and other major structures
- Nilfs2: add maintainer
- Nilfs2: another dat for garbage collection
- Nilfs2: avoid double error caused by nilfs_transaction_end
- Nilfs2: block cache for garbage collection
- Nilfs2: B-tree based block mapping
- Nilfs2: B-tree node cache
- Nilfs2: buffer and page operations
- Nilfs2: checkpoint file
- Nilfs2: clean up indirect function calling conventions
- Nilfs2: cleanup nilfs_clear_inode
- Nilfs2: clean up sketch file
- Nilfs2: direct block mapping
- Nilfs2: directory entry operations
- Nilfs2: disk address translator
- Nilfs2: disk format and userland interface
- Nilfs2: extend nilfs_sustat ioctl struct
- Nilfs2: file operations
- Nilfs2: fix buggy behavior seen in enumerating checkpoints
- Nilfs2: fix gc failure on volumes keeping numerous snapshots
- Nilfs2: fix improper return values of nilfs_get_cpinfo ioctl
- Nilfs2: fix missed-sync issue for do_sync_mapping_range()
- Nilfs2: fix problems of memory allocation in ioctl
- Nilfs2: inode map file
- Nilfs2: inode operations
- Nilfs2: insert explanations in gcinode file
- Nilfs2: integrated block mapping
- Nilfs2: introduce secondary super block
- Nilfs2: ioctl operations
- Nilfs2: mark minor flag for checkpoint created by internal operation
- Nilfs2: meta data file
- Nilfs2: operations for the_nilfs core object
- Nilfs2: pathname operations
- Nilfs2: persistent object allocator
- Nilfs2: recovery functions
- Nilfs2: remove compat ioctl code
- Nilfs2: remove timedwait ioctl command
- Nilfs2: replace BUG_ON and BUG calls triggerable from ioctl
- Nilfs2: segment buffer
- Nilfs2: segment constructor
- Nilfs2: segment usage file
- Nilfs2: simplify handling of active state of segments
- Nilfs2: super block operations
- Nilfs2: super block operations fix endian bug
- Nilfs2: support nanosecond timestamp
- Nilfs2: update makefile and Kconfig
- Nilfs2: use fixed sized types for ioctl structures
- Nilfs2: use unlocked_ioctl
Various
- CIFS: Add support for posix open during lookup
- Documentation/filesystems: remove out of date reference to BKL being held
- documentation: update Documentation/filesystem/proc.txt and Documentation/sysctls
- Document /proc/fs/nfsd/pool_stats
- filesystem freeze: allow SysRq emergency thaw to thaw frozen filesystems
- GFS2: Merge lock_dlm module into GFS2
- nfs41: common protocol definitions
- nfsd41: control nfsv4.1 svc via /proc/fs/nfsd/versions
- nfsd41: Documentation/filesystems/nfs41-server.txt
- ocfs2: Add a name indexed b-tree to directory inodes
- ocfs2: Introduce dir free space list
- ocfs2: Introduce dir lookup helper struct
- ocfs2: Store dir index records inline
- quota: Add quota reservation support
- ramfs: add support for "mode=" mount option
- reiserfs: rework reiserfs_panic
- reiserfs: rework reiserfs_warning
- reiserfs: use generic readdir for operations across all xattrs
- UBIFS: add R/O compatibility
- udf: implement mode and dmode mounting options
- vfat: Note the NLS requirement
- xfs: Update maintainers
Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich in vorangegangen Ausgaben des Kernel-Logs auf heise open. (thl/c't) (thl)