Ext4 Dateisystem

Dieser Artikel gibt eine kurze Einführung in das Linux Dateisystem Ext4, dem Nachfolger des Linux Dateisystems Ext3. Es werden einige Tipps bezüglich dem Einsatz gegeben sowie weiterführende Links angegeben.

Entstehung

Um einige vorhandenen Einschränkungen des bisherigen Ext2, und Ext3 Dateisystems in Zukunft zu beseitigen, wurde der Source Code von ext3 geforked und eigenständig weiterentwickelt. Mit Kernel 2.6.19 wurde Ext4 in den Linux Kernel aufgenommen und schlussendlich mit Kernel 2.6.28 als stabil erklärt.

Aktuelle Distributionen wie RedHat Enterprise Linux 6 (RHEL), Debian 6.0 (Squeeze) oder Ubuntu 10.10 (Maverick Meerkat) bieten eine stabile Ext4 Unterstützung an und setzten es teilweise auch als Default Dateisystem ein.

Vorteile

• verbesserte Performance durch
  • Multi-block allocation
  • Extent-based block mapping
  • Delayed allocation
  • Stripe-aware allocation
• verbesserte Datensicherheit durch
  • Write barriers
• Zeitstempel im Nanosekunde-Bereich statt nur im Sekundenbereich
• Geschwindigkeit von e2fsck erhöht
• Unlimitierte Anzahl an Unterverzeichnissen (bei Ext3: 32 000 Unterverzeichnisse innerhalb eines Verzeichnisses)
• Journaling der Quota Daten: dadurch entfällt ein Quota Check nach einem Systemabsturz

Weitere Details zu den Vorteilen erhalten Sie im Whitepaper von Red Hat ^[1].

Kompatiblität mit ext3

Da es sehr viele Änderungen im Vergleich zu Ext3 gegeben hat, ist die Migration nach Ext4 nicht so einfach wie von Ext2 nach Ext3.

Um alle Vorteile des Ext4 Dateisystems nutzen zu können, wird von Red Hat für RHEL 6 empfohlen ein Backup der Daten zu erstellen, das Ext4 Dateisystem neu zu erstellen und die Daten in das neue Ext4 Dateisystem zu kopieren (siehe auch ^[1]).

Der Ext4 Treiber unterstützt zwar das Mounten eines Ext3 Dateisystems, jedoch nur mit eingeschränktem Funktionsumfang. Umgekehrt ist das Mounten eines Ext4 Dateisystems als Ext3 Dateisystem nicht mehr möglich, sobald man Verwendung des Extent-basierten Mappings macht.

SSD Optimierungen

ATA Trim

Ext4 unterstützt ATA Trim für SSDs:

• Online Discard ab Kernel 2.6.33
  • Mount-Option -o discard (Beispiel mount -o discard /dev/sdb1 /mnt/, für eine permanente Aktivierung muss die Option in /etc/fstab eingetragen werden, da discard standardmäßig deaktiviert ist)^[2]
• Batched Discard ab Kernel 2.6.37
  • beschleunigtes Batched Discard ab Kernel 3.1
• Pre-Discard beim Formatieren ab mke2fs 1.41.10^[3][4][5]
  • Auszug aus der Manpage von mke2fs: -E discard: Attempt to discard blocks at mkfs time (discarding blocks initially is useful on solid state devices and sparse / thin-provisioned storage). When the device advertises that discard also zeroes data (any subsequent read after the discard and before write returns zero), then mark all not-yet-zeroed inode tables as zeroed. This significantly speeds up filesystem initialization. This is set as default.
    • Achtung beim Einsatz mit dem Device Mapper mit gemischten Physical Volumes: erst ab Kernel 3.0 wird discard_zeros_data richtig zurückgegeben - siehe Patch block: Fix discard topology stacking and reporting)
  • In unseren Tests konnten wir deutlich unterschiedlich lange Zeiten für das Discard beim Formatieren beobachten. Große Auswirkungen von discard also zeroes data konnten wir dabei nicht festestellen (siehe dazu ATA Trim Performance).
  • Bei discard also zeroes data zeigt hdparm -I Deterministic read ZEROs after TRIM (ansonsten Deterministic read data after TRIM). Das folgende Beispiel zeigt eine OCZ Vertex 3 SSD und eine Intel 320 Series SSD:

[root@fedora15 ~]# hdparm -V
hdparm v9.36
[root@fedora15 ~]# hdparm -I /dev/sda | grep 'Model\|TRIM'
	Model Number:       OCZ-VERTEX3                             
	   *	Data Set Management TRIM supported (limit 1 block)
	   *	Deterministic read data after TRIM
[root@fedora15 ~]# hdparm -I /dev/sdb | grep 'Model\|TRIM'
	Model Number:       INTEL SSDSA2CW160G3                     
	   *	Data Set Management TRIM supported (limit 8 blocks)
	   *	Deterministic read ZEROs after TRIM
[root@fedora15 ~]# 

Dateisystem Journal: ja oder nein?

Ein Verzicht auf das Dateisystem Journal von Ext4^[6][7] kann die Performance des Dateisystems erhöhen, ist aber mit Nachteilen bei einem unsauberen Herunterfahren (z.B. bei einem Stromausfall) verbunden. Ext4 Dateisystementwickler Theodore Tso hat in Tests festgestellt, dass die Performancenachteile durch Journaling nur zwischen vier und zwölf Prozent betragen. Das Journal sollte daher also trotzdem verwendet werden, ein Verzicht auf die Protokollierung der atime ist hier zur Performancesteigerung eher zu empfehlen.^[8][9]

noatime

Die Verwendung der Mount-Option noatime verbessert die Performance bei Lesezugriffen.^[8][10][11]

stride und stripe-width Parameter verwenden?

Es finden sich immer wieder Empfehlungen bestimmte Werte für die stride und stripe-width Parameter^[12][13] von Ext4 für SSDs zu verwenden.^[14][15]

Ob bestimmte Werte hier tatsächlich einen Nutzen bringen lässt sich allerdings derzeit nicht mit Sicherheit allgemein sagen. Es sind dazu individuelle Tests mit der jeweiligen SSD notwendig.^[16][17]

Lazy Initialization

Beim Erstellen eines ext4-Filesystems müssen die vorhandenen Bereiche der Inode-Tabellen bereinigt werden (mit Nullen überschrieben - "zeroed"). Das Feature "lazyinit" soll das Anlegen eines Filesystems deutliche beschleunigen, indem es beim Erstellen nicht sofort alle Inode-Tabellen initialisiert, sondern dies erst nach und nach beim erstem Mount im Hintergrund durchführt (ab Kernel-Version 2.6.37).^[18][19] Dazu der Auszug aus der man-Page von mkfs.ext4:^[20]

If enabled and the uninit_bg feature is enabled, the inode table will not be fully initialized by mke2fs. This speeds up filesystem initialization noticeably, but it requires the kernel to finish initializing the filesystem in the background when the filesystem is first mounted. If the option value is omitted, it defaults to 1 to enable lazy inode table zeroing.

Vorsicht ist geboten, wenn mit einem frisch erstellten Filesystem Performance-Tests durchgeführt werden. Die "lazy initialization" kann nach dem ersten Mounten einiges an Daten auf die Festplatte schreiben und somit die Testergebnisse verfälschen. Der Kernel-Prozess "ext4lazyinit" schreibt zu Beginn bis zu 16000kB/s auf das Device und verursacht somit einiges an Bandbreite zur Festplatte (s.a. Per Prozess I/O Statistiken). Um die Lazy Initialization zu verhindern werden beim Befehl mkfs.ext4 erweiterte Optionen angegeben:^[20]

mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/mapper/fc-root

Mit der Angabe dieser Optionen werden die Inodes sowie das Journal direkt beim Erstellen initialisiert.

Mögliche Probleme

Schlechte Performance durch Write Barriers

Durch Write Barriers kann die Integrität des Dateisystems gewährleistet werden, wenn die eingesetzte Festplatte einen flüchtigen Cache einsetzt und der Cache-Inhalt durch einen Stromausfall verloren geht. Dies verbessert somit die Datensicherheit jedoch mit dem Preis eines kleinen Performancenachteils. Per Default sind die Write Barriers aktiviert, sie können jedoch mit der Dateisystem Option nobarrier abgeschaltet werden. Dies ist jedoch nur dann zu empfehlen wenn der Write Cache Ihres RAIDs mit einer BBU, Zero Maintenance Cache oder ähnlichem abgesichert ist.

Datenverlust bei Applikationen die fsync() nicht korrekt verwenden

Als Ext4 bei den ersten Distributionen eingeführt wurde, gab es bald Meldungen über teilweise massiven Datenverlust.^[21]

Der Grund dafür ist delayed allocation, welchen den notwendigen Speicherplatz erst bis zu 60 Sekunden später allokiert. Dadurch kann es zum Beispiel bei einem Rename einer Datei zu dem Szenario kommen, dass die Metadaten den Rename bereits korrekt abbilden aber die eigentlichen Daten noch nicht geschrieben wurden. Dadurch verweist der Dateiname auf eine 0 Byte Datei. Dies passiert jedoch nur dann, wenn eine Applikationen die fsync() Funktion nicht korrekt benutzt. Laut dem Entwickler Theodore Ts'o implementiert Ext4 den POSIX Standard für Dateioperationen exakt. Das Problem ist jedoch, dass das "sicherere" Verhalten von Ext3 ungewollt war, jedoch von vielen Anwendungsentwicklern aufgrund der großen Verbreitung als gegeben angesehen wurde.

Als Workaround wurde zuerst der "alloc_on_commit" Modus eingeführt, welcher kurze Zeit später mit Kernel 2.6.30 durch den Modus "auto_da_alloc" ersetzt wurde (siehe Kernel Commit ^[22]). Dadurch wird versucht häufig auftretende Fälle für potentiellen Datenverlust zu erkennen und zu vermeiden. Dieser Modus wurde zum neuen Default Modus, kann jedoch durch "noauto_da_alloc" deaktiviert werden.

Generell sollten sich Applikationen in Zukunft besser an den POSIX Standard halten und fsync() an den notwendigen Stellen einsetzen. Ext4 wurde aufgrund der Ext3 Vorgeschichte für diese Problemfälle nachträglich optimiert, andere Dateisysteme mit delayed allocation (z.B. XFS oder Btrfs) nehmen darauf keine Rücksicht.

Eizelnachweise

1. ↑ ^{1,0 1,1} White Paper: "Is It Time to Migrate Your File Systems to Ext4?" von Krista Guglielmeti, (Login erforderlich!)
2. ↑ http://www.kernel.org/doc/Documentation/filesystems/ext4.txt
3. ↑ e2fsprogs Release Notes e2fsprogs 1.41.10 (February 10, 2010): Mke2fs will use BLKDISCARD to pre-discard all blocks on an SSD or thinly-provisioned storage device.
4. ↑ e2fsprogs Release Notes e2fsprogs 1.41.13 (December 13, 2010): Mke2fs now understands the extended option "discard" and "nodiscard", and the older option -K is deprecated. The default of whether discards are enabled by default can be controled by the mke2fs.conf file., mke2fs: Deprecate -K option, introduce discard/nodiscard (commit)
5. ↑ Korrektur der Manpage (kommt vermutlich in e2fsprogs 1.41.15, per 3.7.2011 ist 1.41.14 die aktuellste Version): mke2fs: Simple man page nodiscard option correction (commit)
6. ↑ Ext4: "No Journaling" mode (kernelnewbies.org)
7. ↑ ext4: Allow ext4 to run without a journal (Kernel Commit)
8. ↑ ^{8,0 8,1} SSD’s, Journaling, and noatime/relatime (Theodore Tso's blog, 01.03.2009)
9. ↑ Re: Ext4 on SSD Intel X25-M (Linux Ext4 Mailing List, 12.11.2009)
10. ↑ Linux: Replacing atime With relatime (kerneltrap.org)
11. ↑ Does noatime imply nodiratime? (lwn.net)
12. ↑ [1] (Ext4 Wiki), siehe dort s_raid_stride, s_raid_stripe_width
13. ↑ Creating and Tuning ext4 Partitions (blog.peacon.co.uk)
14. ↑ Optimizing Linux for SSD usage (searchenterpriselinux.techtarget.com)
15. ↑ http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux
16. ↑ Re: -E stride and stripe-width necessary for best performace of SSDs? (Linux Ext4 Mailing List, 01.07.2011)
17. ↑ Re: -E stride and stripe-width necessary for best performace of SSDs? (Linux Ext4 Mailing List, 01.07.2011)
18. ↑ Kernel-Log – Was 2.6.37 bringt (2): Dateisysteme (heise.de, 05.12.2010)
19. ↑ ext4: add support for lazy inode table initialization (git.kernel.org, 28.10.2010)
20. ↑ ^{20,0 20,1} mkfs.ext4 man Page (linux.die.net)
21. ↑ Möglicher Datenverlust bei Ext4 (heise.de)
22. ↑ GIT Kernel Commit für Ext4 auto_da_alloc Modus

Weitere Informationen

• Ext4 (en.wikipedia.org)
• Ext4 Wiki (ext4.wiki.kernel.org)
• Chapter 9. The Ext4 File System (Red Hat Enterprise Linux 6 Storage Administration Guide)

• Thomas Krenn steht für Server Made in Germany.
  Wir assemblieren und liefern europaweit innerhalb von 24 Stunden.
  Unter www.thomas-krenn.com können Sie Ihre Server individuell konfigurieren.