Ext4 Dateisystem

Aus Thomas-Krenn-Wiki
Zur Navigation springen Zur Suche springen

Ext4 ist ein block-basiertes journaling Linux Dateisystem und Nachfolger des Dateisystems Ext3. Ext4 wurde erstmals in den Linux Kernel 2.6.19 aufgenommen und mit Kernel 2.6.28 als stabil eingestuft. In diesem Artikel zeigen wir Ihnen die Vorteile gegenüber Ext3, Informationen wie Sie Ext4 nutzen sowie wertvolle Hintergrundinformationen, die Ihnen im laufenden Betrieb beim Ext4 Einsatz helfen.

Vorteile im Vergleich zu Ext3

Ext4 bietet im Vergleich zu Ext3 die folgenden 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
  • Integrierte Verschlüsselung (ab Linux Kernel 4.1)

Weitere Details zu den Vorteilen erhalten Sie in einem Whitepaper von Red Hat.[1]

Anwendung

Die folgenden Beispiele zeigen ein Ext4 Dateisystem, das auf einem LVM Logical Volume eingerichtet wird (wie in LVM Grundkonfiguration beschrieben).

Dateisystem erstellen - mkfs.ext4

Zum Erstellen (Formatieren) eines neuen Dateisystems verwenden Sie das Kommando mkfs.ext4 und geben das gewünschte Block-Device an (vollständige Beispielausgabe):

mkfs.ext4 /dev/vg00/ext4fs

Wichtiger Hinweis: Bereits vorhandene Daten auf dem angeführten Block-Device werden damit überschrieben.

Lazy Initialization

Beim Erstellen eines Ext4-Filesystems müssen die vorhandenen Bereiche der Inode-Tabellen bereinigt werden (mit Nullen überschrieben - "zeroed"). Das Funktion "lazyinit" beschleunigt das Anlegen eines Dateisystems deutlich, 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).[2][3] Dazu der Auszug aus der man-Page von mkfs.ext4:[4]

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:[4]

mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/vg00/ext4fs

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

Dateisystem einbinden - mount

Mit dem mount Kommando binden Sie ein Dateisystem ein. Falls nicht vorhanden, müssen Sie den Mountpoint zuvor erstellen:

mkdir /mnt/ext4fs
mount /dev/vg00/ext4fs /mnt/ext4fs

Seit Linux Kernel 3.4 finden Sie im Proc-Dateisystem die verwendeten Mount Optionen. Beachten Sie dabei, dass bei Logical Volumes der Device-Mapper Name (hier dm-0) zu verwenden ist (vollständige Beispielausgabe):

cat /proc/fs/ext4/dm-0/options

Dateisystem analysieren - tune2fs

Mit dem Kommando tune2fs zeigen Sie Parameter des Dateisystems an (vollständige Beispielausgabe):

tune2fs -l /dev/vg00/ext4fs

Dateisystemcheck - e2fsck

Einen Dateisystemcheck führen Sie mit dem e2fsck Kommando aus, ggf. mit dem Parameter -f (vollständige Beispielausgabe):

e2fsck /dev/vg00/ext4fs

Dateisystem vergrößern - resize2fs

Das Vergrößern eines Ext4-Dateisystems kann in einer LVM-Umgebung wie in diesem Beispiel direkt mit dem lvextend Kommando in einem Schritt durchgeführt werden. Voraussetzung ist, dass die entsprechende LVM Volume Group noch über ausreichend freien Speicherplatz verfügt. Der Parameter -r bewirkt, dass nach dem Vergrößern des LVM Logical Volumes das Ext4-Kommando resize2fs ausgeführt, und damit das Dateisystem vergrößert wird. Das Vergößern ist online möglich, d.h. das Dateisystem kann gemountet bleiben.

Das Kommando können Sie folgendermaßen ausführen (vollständige Beispielausgabe):

lvextend -L +10G -r /dev/vg00/ext4fs

Alternativ können Sie beiden Schritte auch manuell hintereinander ausführen (vollständige Beispielausgabe):

lvextend /dev/vg00/ext4fs -L +10G
resize2fs /dev/vg00/ext4fs

Dateisystem verkleinern - resize2fs

Empfehlung: Stellen Sie vor dem Verkleinern eines Dateisystems immer sicher, dass Sie über ein aktuelles Backup verfügen, da bei Fehlern beim Verkleinern Datenverlust droht.

Auch das Verkleinern eines Ext4-Dateisystems kann in einer LVM-Umgebung in einem Schritt durchgeführt werden - mit dem lvreduce Kommando. Auch hier bewirkt der -r Parameter, dass ein resize2fs ausgeführt wird - hier nun vor dem Verkleinern des LVM Logical Volumes. Das Verkleinern ist ausschließlich offline möglich, d.h. das Dateisystem darf nicht gemountet sein:

Das Kommando können Sie folgendermaßen ausführen (vollständige Beispielausgabe):

umount /mnt/ext4fs
lvreduce -L -10G -r /dev/vg00/ext4fs

Auch hier können die Schritte manuell durchführt werden. Dabei wird ersichtlich, dass vor dem Verkleinern ein Dateisystemcheck erforderlich ist (vollständige Beispielausgabe):

umount /mnt/ext4fs
e2fsck -f /dev/vg00/ext4fs
resize2fs /dev/vg00/ext4fs 60G
lvreduce -L 60G /dev/vg00/ext4fs

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)[5]
  • Batched Discard ab Kernel 2.6.37
  • Pre-Discard beim Formatieren ab mke2fs 1.41.10[6][7][8]
    • 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.
    • 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[9][10] 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.[11][12]

noatime

Die Verwendung der Mount-Option noatime verbessert die Performance bei Lesezugriffen.[11][13][14]

stride und stripe-width Parameter verwenden?

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

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.[18][19]

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 Battery Backup Unit (BBU) oder einem anderen Cache Schutzmechanismus wie Adaptec Zero Maintenance Cache Protection oder LSI CacheVault 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.[20]

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 [21]). 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. White Paper: "Is It Time to Migrate Your File Systems to Ext4?" von Krista Guglielmeti, (Login erforderlich!)
  2. Kernel-Log – Was 2.6.37 bringt (2): Dateisysteme (heise.de, 05.12.2010)
  3. ext4: add support for lazy inode table initialization (git.kernel.org, 28.10.2010)
  4. 4,0 4,1 mkfs.ext4 man Page (linux.die.net)
  5. http://www.kernel.org/doc/Documentation/filesystems/ext4.txt
  6. 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.
  7. 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)
  8. 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)
  9. Ext4: "No Journaling" mode (kernelnewbies.org)
  10. ext4: Allow ext4 to run without a journal (Kernel Commit)
  11. 11,0 11,1 SSD’s, Journaling, and noatime/relatime (Theodore Tso's blog, 01.03.2009)
  12. Re: Ext4 on SSD Intel X25-M (Linux Ext4 Mailing List, 12.11.2009)
  13. Linux: Replacing atime With relatime (kerneltrap.org)
  14. Does noatime imply nodiratime? (lwn.net)
  15. [1] (Ext4 Wiki), siehe dort s_raid_stride, s_raid_stripe_width
  16. Optimizing Linux for SSD usage (searchenterpriselinux.techtarget.com)
  17. http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux
  18. Re: -E stride and stripe-width necessary for best performace of SSDs? (Linux Ext4 Mailing List, 01.07.2011)
  19. Re: -E stride and stripe-width necessary for best performace of SSDs? (Linux Ext4 Mailing List, 01.07.2011)
  20. Möglicher Datenverlust bei Ext4 (heise.de)
  21. GIT Kernel Commit für Ext4 auto_da_alloc Modus

Weitere Informationen


Foto Christoph Mitasch.jpg

Autor: Christoph Mitasch

Christoph Mitasch arbeitet in der Abteilung Web Operations & Knowledge Transfer bei Thomas-Krenn. Er ist für die Betreuung und Weiterentwicklung der Webshop Infrastruktur zuständig. Seit einem Studienprojekt zum Thema Hochverfügbarkeit und Daten Replikation unter Linux beschäftigt er sich intensiv mit diesem Themenbereich. Nach einem Praktikum bei IBM Linz schloss er sein Diplomstudium „Computer- und Mediensicherheit“ an der FH Hagenberg ab. Er wohnt in der Nähe von Linz und ist neben der Arbeit ein begeisterter Marathon-Läufer und Jongleur, wo er mehrere Weltrekorde in der Team-Jonglage hält.


Foto Werner Fischer.jpg

Autor: Werner Fischer

Werner Fischer arbeitet im Product Management Team von Thomas-Krenn. Er evaluiert dabei neueste Technologien und teilt sein Wissen in Fachartikeln, bei Konferenzen und im Thomas-Krenn Wiki. Bereits 2005 - ein Jahr nach seinem Abschluss des Studiums zu Computer- und Mediensicherheit an der FH Hagenberg - heuerte er beim bayerischen Server-Hersteller an. Als Öffi-Fan nutzt er gerne Bus & Bahn und genießt seinen morgendlichen Spaziergang ins Büro.


Das könnte Sie auch interessieren

Block-basierte Linux Dateisysteme
Linux Dateisysteme
Lsusb