What makes ext4 different
`mkfs.ext4 /dev/sda1` — that command runs on almost every Linux server, from a Raspberry Pi to a rack unit in a data center. This article explains what makes ext4 different from its predecessors, where the limits lie, and how to set up and check an ext4 volume.
Requirements
You need a Linux system with kernel 2.6.28 or newer — that is any distribution released since 2009. You also need root access and an unused partition or disk on which you want to create a file system. For the examples in this article, I use Ubuntu 24.04 LTS, but the commands work unchanged on Debian, RHEL, Rocky, and most other distributions. The `e2fsprogs` package version must be 1.42 or higher; you can check that with `e2fsprogs --version`.What makes ext4 different
ext4 is not a new design, but an evolutionary step from ext3. The kernel documentation therefore calls it an "extending" file system: it retains the structure of its predecessor and adds functionality to it. That approach has one major advantage: you can upgrade an existing ext3 volume without reformatting. Your data stays in place, the partition table remains intact, and you gain the new capabilities.The core improvement lies in the way ext4 tracks files on disk. ext2 and ext3 used a block map: a list of all the individual blocks that a file occupies. With large files, that list becomes long, costing metadata and time. ext4 instead uses extents: contiguous runs of blocks that you register as a single unit. You describe a 100 MB file not with tens of thousands of individual block references, but with a handful of extent references. This yields gains especially when reading and writing large files.
Additionally, ext4 records timestamps with nanosecond precision, where ext3 was stuck at seconds. That seems like a detail, but for audit logging and applications that need exact time recording, the difference between seconds and nanoseconds is the difference between a suspicion and proof.
Journaling: the guardrail of ext4
ext4 inherits the journal mechanism from ext3. The principle: before the file system modifies metadata, it first writes that change to a log — the journal. Only then does it actually perform the change. If the system dies halfway through due to a power outage or a kernel panic, the file system can replay the journal at the next mount and restore the metadata to a consistent state. Without a journal, you would have to run a full `fsck` after every crash and hope nothing was lost.ext4 has three journal modes, each offering a different compromise between speed and safety:
- `writeback` journals only metadata, not file content. Fast, but after a crash a file can contain metadata that points to data that was never written out.
- `ordered` (the default) also journals only metadata, but forces the data blocks to be written to disk before the associated metadata. A file that appears after a crash then contains no garbage.
- `journal` writes all data to the journal first and only then to its final location. Safest, but also slowest, because every write operation happens twice.
The limits of ext4
ext4 supports volumes up to 1 exbibyte (EiB) and individual files up to 16 tebibytes (TiB), according to the specifications maintained by Oracle. In practice, those limits are far beyond what you put on a single file system — most servers run with volumes of a few terabytes.What ext4 does not have is copy-on-write. File systems like Btrfs and ZFS never write data over existing blocks, but to new blocks and only then switch over. That makes snapshots, built-in compression, and checksum verification across the entire data path possible. ext4 has none of that. If you want a snapshot of an ext4 volume, you have to solve it at another level — with LVM snapshots, or with a backup tool that works at the file level.
That sounds like a shortcoming, but it is also a choice for simplicity. Copy-on-write file systems are more complex, consume more memory, and have a longer learning curve. On a standard server where you just want a reliable file system that does not cause surprises, that complexity is often unnecessary.
Setting up an ext4 volume
The steps below take you from a bare partition to a mounted ext4 volume that is automatically available at every reboot.1. Identify the correct disk
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
This shows all disks and partitions with their current file system. Note the name of the partition you want to format — for example `/dev/sdb1`. Double-check that you have the right disk. Formatting the wrong device means guaranteed data loss, and there is no undo for that.
2. Create the ext4 file system
sudo mkfs.ext4 /dev/sdb1
This command formats the partition with ext4. Add `-L datavolume` to give it a label — useful if you later manage multiple volumes and do not want to guess which disk is which. The command asks for confirmation if the device already contains a file system. Read that message, type `y`, and only then does something happen.
3. Create a mount point
sudo mkdir -p /mnt/data
This is the directory where the filesystem becomes visible. Choose a name that describes what will be stored on it. A mount point like `/mnt/backup` will still tell you three months from now what belongs on that disk; `/mnt/data1` will not.
4. Mount the filesystem
sudo mount /dev/sdb1 /mnt/data
The partition is now accessible via `/mnt/data`. Check with `df -h /mnt/data` whether the volume is mounted correctly and what the available space is.
5. Arrange mounting at boot
echo "UUID=$(sudo blkid -s UUID -o value /dev/sdb1) /mnt/data ext4 defaults,noatime 0 2" | sudo tee -a /etc/fstab6. Test the fstab configuration
sudo umount /mnt/data && sudo mount -a
With `mount -a`, the system reads `/etc/fstab` and mounts everything listed there. If this command returns without an error message, your configuration is correct. An error in `/etc/fstab` can cause the system to fail to boot at the next restart — that is why you test this now, not at a reboot.
Verification
Check whether the filesystem functions correctly:df -h /mnt/data
sudo tune2fs -l /dev/sdb1 | grep "Filesystem features"The first command shows the mounted volume with the available space. The second shows the active features of the filesystem — you should see, among others, `extents`, `has_journal`, and `flex_bg` in the list. If `has_journal` is missing, the volume is running without a journal, and you are one crash away from an inconsistent filesystem.
Common problems
The system does not boot after an fstab change You made a mistake in `/etc/fstab`. Boot from a live USB, mount the root partition, and remove or correct the faulty line. Prevention is better: after every fstab change, run `sudo mount -a` and check for error messages.Files are slow to open after a crash The journal has been replayed and the filesystem is consistent, but the block cache is empty. This is normal and resolves itself within a few minutes as the system loads data back into memory.
`mkfs.ext4` refuses to run on a partition marked as swap You must first disable swap with `sudo swapoff /dev/sdb1`, repartition the drive without the swap flag, and only then format it.
What ext4 is and is not for
For most workloads — a web server, a database with its own backup strategy, a file server for a small team — ext4 is the safe choice. It is extensively tested, the tooling is mature, and the chance of encountering an unexpected issue is small. That is more than can be said for the newer filesystems, which still have to prove their stability on production servers.If you need snapshots, compression, or checksum verification, you will have to look further. But weigh whether you actually use those features, or whether you just like how they sound in a presentation. A Btrfs volume with snapshots you never roll back is more complex than an ext4 volume with a simple nightly backup — and the backup also works if your disk physically fails.