Ext4 Dateisystem
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
(Beispielmount -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]
- Mount-Option
- Batched Discard ab Kernel 2.6.37
- beschleunigtes Batched Discard ab Kernel 3.1
- 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.
- 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:
- 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.
[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
- ↑ White Paper: "Is It Time to Migrate Your File Systems to Ext4?" von Krista Guglielmeti, (Login erforderlich!)
- ↑ Kernel-Log – Was 2.6.37 bringt (2): Dateisysteme (heise.de, 05.12.2010)
- ↑ ext4: add support for lazy inode table initialization (git.kernel.org, 28.10.2010)
- ↑ 4,0 4,1 mkfs.ext4 man Page (linux.die.net)
- ↑ http://www.kernel.org/doc/Documentation/filesystems/ext4.txt
- ↑ 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.
- ↑ 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)
- ↑ 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)
- ↑ Ext4: "No Journaling" mode (kernelnewbies.org)
- ↑ ext4: Allow ext4 to run without a journal (Kernel Commit)
- ↑ 11,0 11,1 SSD’s, Journaling, and noatime/relatime (Theodore Tso's blog, 01.03.2009)
- ↑ Re: Ext4 on SSD Intel X25-M (Linux Ext4 Mailing List, 12.11.2009)
- ↑ Linux: Replacing atime With relatime (kerneltrap.org)
- ↑ Does noatime imply nodiratime? (lwn.net)
- ↑ [1] (Ext4 Wiki), siehe dort s_raid_stride, s_raid_stripe_width
- ↑ Optimizing Linux for SSD usage (searchenterpriselinux.techtarget.com)
- ↑ http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux
- ↑ Re: -E stride and stripe-width necessary for best performace of SSDs? (Linux Ext4 Mailing List, 01.07.2011)
- ↑ Re: -E stride and stripe-width necessary for best performace of SSDs? (Linux Ext4 Mailing List, 01.07.2011)
- ↑ Möglicher Datenverlust bei Ext4 (heise.de)
- ↑ GIT Kernel Commit für Ext4 auto_da_alloc Modus
Weitere Informationen
- Ext4 (en.wikipedia.org)
- Ext4 Wiki (ext4.wiki.kernel.org)
- The Ext4 File System (Red Hat Enterprise Linux 7 Storage Administration Guide)
- Das Linux-Dateisystem Ext4 (heise.de, 26.05.2009)
- EXT4 File-System Tuning Benchmarks (phoronix.com, 16.11.2012)
- Chapter 22. Write Barriers (access.redhat.com/documentation)
- Ext4 Filesystem (www.kernel.org/doc)
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.
|
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.
|