ext4 data=journal Is Deprecated in Linux 7.3

Somewhere on your fleet there is a database box that someone set to data=journal in 2019 because a blog post said it was safer, and nobody has touched it since. Linux 7.3 puts a deprecation notice on that decision: ext4 data=journal is deprecated, with removal planned for early 2028.

Nothing breaks today. But a deprecation with a date is a gift, because you get roughly a year and a half to find every machine using ext4 data=journal and move it somewhere sensible. This post explains what the mode does, what it costs, how to audit for it, and how to migrate without drama.

What changed in Linux 7.3

Phoronix reported on 8 October 2026 that ext4 deprecates its journaled data=journal mode, with the mode planned for removal in early 2028, following the 2027 LTS kernel. Linux 7.3-rc7 was released on Sunday 11 October, and the final 7.3 release is expected around 18 October unless an rc8 is needed. That means the deprecation notice arrives in a kernel you may be running within weeks.

Deprecated is not removed. Mounting with data=journal keeps working on 7.3, and the plan points at the first kernels of 2028. Treat it like a smoke detector chirping: annoying now, a real problem if you ignore it for two years.

The three ext4 data modes in one minute

ext4 journals metadata always. The data= mount option decides what happens to file contents relative to that journal.

• data=ordered (the default): file data is written to its final location before the related metadata is committed to the journal. Metadata stays consistent and you never see stale blocks exposed by a crash.
• data=writeback: metadata is journaled but data ordering is not enforced. Fastest, and after a crash a file can contain old garbage from previously used blocks.
• data=journal: all data and metadata go through the journal first and are then written to their final location. Every byte is written twice.

That double write is the cost. According to the Phoronix report, journaled mode brings a significant write performance hit compared with ordered mode, and using it also disables delayed allocation and Direct I/O support. Delayed allocation is one of the big reasons ext4 lays out files well, and O_DIRECT is what many databases use to bypass the page cache. Choosing data=journal for a database can quietly turn off the features that database wanted.

Audit: who is using data=journal?

The mode can be requested in four places, and you need to check all of them: the live mount, fstab, the filesystem superblock default mount options, and per-file journaling flags set with chattr. Here is a script that checks the first three on a single host.

#!/usr/bin/env bash
set -euo pipefail

echo "== live ext4 mounts using journal data =="
findmnt -t ext4 -n -o TARGET,SOURCE,OPTIONS | grep -E 'data=journal' || echo "none"

echo
echo "== fstab entries requesting data=journal =="
grep -E '^[^#].*ext4.*data=journal' /etc/fstab || echo "none"

echo
echo "== superblock default mount options =="
for dev in $(findmnt -t ext4 -n -o SOURCE | sort -u); do
  opts=$(tune2fs -l "$dev" 2>/dev/null | awk -F': *' '/Default mount options/ {print $2}')
  printf '%s -> %s\n' "$dev" "$opts"
  case "$opts" in *journal_data*) echo "   ^ journal_data is the filesystem default";; esac
done

The third check matters because tune2fs can bake journal_data into the superblock as a default mount option. In that case /etc/fstab says nothing, and the mode only shows up in findmnt or in tune2fs output. If you inherited a machine, trust the live mount table, not the config files.

Per-file journaling is the sneaky one. The ext4 journal flag can be set on individual files and directories with chattr +j, which gives them journaled data even on a filesystem mounted in ordered mode. Find those with lsattr.

# lsattr prints 'j' in the flags column for journaled-data inodes
sudo lsattr -R /var/lib 2>/dev/null | awk '$1 ~ /j/ {print $2}' | head -50

Measure before you migrate

Do not take any blog post's word, including this one, about what the change does to your workload. fio makes the comparison cheap. Create two scratch filesystems on identical devices, mount one in each mode, and run the same job.

# WARNING: destroys data on /dev/vdb and /dev/vdc
sudo mkfs.ext4 -F /dev/vdb && sudo mkfs.ext4 -F /dev/vdc
sudo mkdir -p /mnt/j /mnt/o
sudo mount -o data=journal /dev/vdb /mnt/j
sudo mount -o data=ordered /dev/vdc /mnt/o

for m in j o; do
  echo "=== /mnt/$m ==="
  sudo fio --name=w --directory=/mnt/$m --rw=randwrite --bs=4k \
       --size=1g --numjobs=4 --iodepth=16 --ioengine=libaio \
       --fsync=32 --runtime=60 --time_based --group_reporting
done

Pay attention to write IOPS and the p99 completion latency, not just the average. The expected shape is lower throughput in journal mode, since every write lands twice, but your hardware and workload decide how much. Note also that with data=journal the kernel will refuse or work around direct I/O, so benchmark with and without --direct=1 if your application uses it.

Migrating off data=journal

The change itself is small. The risk is in the verification, so do it in this order: remove the setting from every place you found it, remount, and prove the live mode changed.

# 1. clear the superblock default (only if it was set there)
sudo tune2fs -o ^journal_data /dev/sdb1

# 2. edit /etc/fstab: replace data=journal with data=ordered (or drop it)
sudo sed -i 's/data=journal/data=ordered/' /etc/fstab

# 3. a plain remount cannot change the data mode, so schedule a real unmount
sudo systemctl stop myapp.service
sudo umount /srv/data && sudo mount /srv/data
sudo systemctl start myapp.service

# 4. verify
findmnt -n -o TARGET,OPTIONS /srv/data

If you used data=journal because you were worried about torn writes in a database, the better answer is usually in the database: keep its write-ahead log and full-page writes enabled, call fsync where durability matters, and use a filesystem or storage that gives you the guarantees you actually need. If you truly need data checksums and copy-on-write semantics, a different filesystem is a design decision, not a mount flag.

Gotchas and the takeaway

• Check all four places: live mount, fstab, superblock defaults and chattr +j flags.
• Do not benchmark on the production volume. Use identical scratch devices.
• Do not assume your distro kernel has 7.3. The deprecation matters when you adopt it, and the removal matters for kernels released in 2028.
• Keep an eye on the final Linux 7.3 release notes in case the timeline changes.

ext4 data=journal was always a trade: safety on paper for throughput and features in practice. Linux 7.3 is the signal to look at that trade again. Run the audit script this week, benchmark one representative host, and migrate on your schedule instead of discovering the removal during an upgrade in 2028.