EXT4 erklärt data=journal für veraltet: Aus im Januar 2028

Der EXT4-Betreuer Theodore Ts'o hat den Mount-Modus data=journal offiziell für veraltet erklärt. Linus Torvalds hat die Änderung am 8. Oktober 2026 in den Hauptzweig von Linux 7.3 übernommen, die Unterstützung soll im Januar 2028 entfallen. Ab Linux 7.3 warnt der Kernel bei jedem Mount mit diesem Modus. Betroffen sind nur Systeme, die EXT4 ausdrücklich mit vollständigem Daten-Journaling betreiben, per /etc/fstab, Kernel-Parameter oder Superblock-Standardoption.

Wer EXT4 mit den Voreinstellungen nutzt, ist nicht betroffen: Der Standardmodus ist data=ordered, und XFS-, Btrfs- oder ZFS-Systeme berührt die Änderung gar nicht. Heute muss niemand handeln. Admins sollten aber betroffene Server inventarisieren und die Umstellung in ein Wartungsfenster deutlich vor 2028 legen, weil sich der Modus nur per Neumount oder Neustart ändern lässt.

Was ist passiert?

Der Commit „ext4: mark data=journal as deprecated“ ändert zwei Dinge. In der Kernel-Dokumentation steht beim Mount-Parameter jetzt, dass das Feature veraltet ist und die Unterstützung im Januar 2028 entfernt wird. In fs/ext4/super.c kommt eine neue Warnung hinzu, die bei jedem Mount mit diesem Modus erscheint:

EXT4-fs: The data=journal mount option is deprecated and support will be removed in January 2028

Ts'o hat den Patch am 24. September 2026 verfasst. In den Hauptzweig gelangte er über den Merge des Tags ext4_for_linus-7.3-rc7, den Torvalds am 8. Oktober 2026 um 15:37 Uhr UTC einspielte. Sie erscheint damit in 7.3-rc7 und im fertigen Linux 7.3. Eine Begründung enthält der Commit nicht. Phoronix ordnet den Zeitpunkt so ein, dass die Entfernung nach dem Long-Term-Kernel des Jahres 2027 erfolgen soll. Im Commit selbst steht nur „January 2028“.

Für wen ist das relevant?

Im Modus data=journal schreibt EXT4 neben Metadaten auch alle Dateidaten zuerst ins Journal. Nach einem Absturz lassen sich so auch Inhalte konsistent wiederherstellen. Der Preis ist hoch: Laut Kernel-Dokumentation ist der Modus meist der langsamste, er schaltet Delayed Allocation und O_DIRECT ab, laut Kernel-Quelltext zusätzlich dioread_nolock und fast_commit. Typische Einsatzorte sind Nischen:

• Server ohne USV, bei denen maximale Datenkonsistenz gewünscht war.
• Embedded-Systeme, Appliances und Industrie-PCs auf SD-Karten oder einfachen SSDs.
• Ältere Installationsvorlagen, die den Modus pauschal in die fstab schrieben.
• Dateisysteme, bei denen tune2fs -o journal_data den Modus als Standardoption im Superblock verankert hat. Diese Variante fällt in der fstab nicht auf.

Wie kritisch ist das?

Es handelt sich weder um eine Sicherheitslücke noch um einen Fehler mit Datenverlust. Bis zur Entfernung funktioniert der Modus weiter. Kritisch wird erst ein Kernel ohne Unterstützung. Ob ein solcher Kernel den Mount dann verweigert oder auf einen anderen Modus ausweicht, legt der Commit nicht fest. Für das Root-Dateisystem könnte ein verweigerter Mount einen nicht startenden Server bedeuten. Deshalb lohnt die Bestandsaufnahme jetzt, solange genug Zeit für geplante Umstellungen bleibt. Offen ist außerdem, ob das Datei-Attribut chattr +j, das laut chattr-Handbuch Daten-Journaling für einzelne Dateien aktiviert, ebenfalls wegfällt. Der Commit erwähnt es nicht.

Was sollten Admins jetzt tun?

• Inventar prüfen: auf jedem Linux-System die gemounteten EXT4-Dateisysteme samt Optionen auflisten und nach data=journal filtern, dazu /etc/fstab und die Kernel-Kommandozeile durchsuchen.
• Superblock-Standardoptionen jedes EXT4-Geräts mit tune2fs -l auslesen und auf journal_data prüfen.
• Nach dem Update auf Linux 7.3 im Kernel-Log nach der neuen Warnung suchen, damit übersehene Systeme auffallen.
• Betroffene Dateisysteme in einem Wartungsfenster auf den Standardmodus data=ordered umstellen. Ein Remount genügt nicht, der Kernel lehnt den Moduswechsel im laufenden Betrieb ab.
• Vorher ein geprüftes Backup ziehen, danach Mount-Optionen und Kernel-Log kontrollieren.
• Den eigentlichen Grund für data=journal neu bewerten: Gegen Stromausfälle helfen USV, Dateisystem-Checksummen oder anwendungsseitige Absicherung meist besser.

Die Prüfung mit Bordmitteln:

# Gemountete EXT4-Dateisysteme mit data=journal
findmnt -t ext4 -o TARGET,SOURCE,OPTIONS | grep data=journal

# fstab und Kernel-Kommandozeile
grep -n 'data=journal' /etc/fstab
grep -o 'rootflags=[^ ]*' /proc/cmdline

# Standardoptionen im Superblock (Gerät anpassen)
tune2fs -l /dev/sda1 | grep -i 'default mount options'

# Hinweise im Kernel-Log
journalctl -k | grep -i 'data=journal'

Steht journal_data in den Standardoptionen, entfernt laut tune2fs-Handbuch das Präfix ^ die Option wieder, etwa mit tune2fs -o ^journal_data /dev/sda1. Wirksam wird das erst beim nächsten Mount.

Einordnung für Unternehmen

Für die meisten KMU ist die Meldung eine kurze Inventaraufgabe. Wer bei der Installation keine eigenen Mount-Optionen gesetzt hat, nutzt in der Regel den Kernel-Standard data=ordered. Relevant wird es bei gewachsenen Systemen, Appliances und Embedded-Geräten mit undokumentierter Konfiguration. Bei Appliances sollten Admins beim Hersteller nachfragen, ob die Firmware den Modus nutzt. Wann Distributionen mit Kernel 7.3 oder neuer ausliefern und ob sie die Warnung in ältere Kernel zurückportieren, ist derzeit offen. Die Zeit bis Januar 2028 reicht, sofern die Umstellung im Lifecycle-Plan steht.

Passende Anleitungen auf S-EDV

• Festplatten unter Linux: Partitionen, LVM und fstab erklärt, wie Mount-Optionen in der fstab sauber gesetzt werden.
• Logs lesen mit journalctl und /var/log hilft beim Auffinden der neuen Kernel-Warnung.
• Restic-Backup automatisieren sichert die Daten vor der Umstellung des Dateisystems.

Quellen

• Linux-Commit: EXT4 markiert data=journal als veraltet
• Merge von ext4_for_linus-7.3-rc7 durch Linus Torvalds
• Kernel-Dokumentation zu EXT4 und den Datenmodi
• Handbuchseite zu tune2fs mit Standard-Mount-Optionen
• Handbuchseite zu chattr mit dem Attribut j
• Phoronix: EXT4 erklärt den Journal-Modus für veraltet