Understanding Linux EXT Filesystems: From EXT2 to EXT4 and Their Core Features

In a previous article I introduced Linux filesystems and their high‑level concepts such as "everything is a file". Here I dive deeper into the EXT family, focusing on metadata structures that provide the logical framework for data storage.

Data storage: structured storage and retrieval of data.

Namespace: a set of naming and organization rules.

Security model: an access‑control policy.

API: functions to manipulate filesystem objects like files and directories.

Implementation: software that realizes the above functions.

EXT Filesystem History

Although written for Linux, the EXT filesystem originated from the Minix operating system, whose filesystem was first released in 1987, five years before Linux. Tracing the EXT family from its Minix roots helps understand modern EXT4.

Minix

When Linus Torvalds wrote the original Linux kernel, he needed a filesystem but did not want to develop one, so he adopted the Minix filesystem created by Andrew S. Tanenbaum for the educational Minix OS. Its code was openly licensed, allowing Torvalds to use it in early Linux releases.

Key Minix structures include:

Boot sector: occupies the first sector of the disk.

Superblock: metadata that defines other filesystem structures and locates them on the physical disk.

Inode bitmap block: tracks which inodes are used or free.

Inodes: 256‑byte blocks storing file information such as size, owner/group IDs, permissions, and three timestamps (access, modification, and inode‑change).

Zone bitmap: tracks usage of data zones.

Data zones: actual locations where file data is stored.

EXT

The original EXT (Extended) filesystem, written by Rémy Card and released with Linux in 1992, was based on the Unix File System (UFS) metadata and the Berkeley Fast File System (FFS). It quickly gave way to EXT2 due to serious limitations.

EXT2

EXT2 became the default Linux filesystem for many years. It shares the basic metadata layout of the original EXT but reserves extra space for future extensions. Like Minix, EXT2 places a boot sector in the first sector of the partition, followed by reserved space used by bootloaders such as GRUB.

Each EXT2 partition is divided into block groups (typically ~8 MiB). Within each group:

The first block of a group is a backup superblock containing metadata. Additional backup superblocks exist in some groups, allowing recovery of a corrupted primary superblock using tools like

dd

or

dumpe2fs

.

Sample

dumpe2fs

output (illustrated with screenshots) shows the metadata stored in the superblock and details of the first two block groups.

Each block group has its own inode bitmap, inode table, and block bitmap, enabling fine‑grained tracking of free inodes and data blocks.

EXT3

EXT3 adds a journal to address the long recovery times of

fsck

after an unclean shutdown. The journal records intended changes before they are written to the main filesystem structures, allowing rapid replay on reboot.

While journaling can slightly reduce write performance, it dramatically cuts recovery time from hours to minutes. Users can choose between performance, data integrity, and safety modes; the author prefers safety.

EXT3 can be converted back to EXT2 by disabling the journal (e.g., remounting with

type=ext2

in

/etc/fstab

), but this is not recommended because it may increase recovery time and risk data loss.

To upgrade an existing EXT2 filesystem to EXT3, add a journal with the appropriate

mke2fs

options (illustrated with a screenshot).

EXT4

EXT4 improves performance, reliability, and capacity. It adds metadata and journal checksums, nanosecond‑resolution timestamps (extending the 2038 problem to 2446), and larger file support.

Data allocation uses extents instead of fixed‑size blocks, allowing a single extent to describe a large contiguous region on disk, reducing the number of pointers needed for large files.

Additional allocation strategies (delayed allocation, preallocation, and block group placement) minimize fragmentation and improve sequential read/write performance.

While EXT2/EXT3 can be mounted as EXT4, many of EXT4’s advanced features are disabled in that mode, so a proper upgrade (backup,

mkfs.ext4

, restore) is recommended.

Inodes

Inodes are the core metadata units of EXT filesystems. They store file size, ownership, permissions, timestamps, and up to 15 pointers to data blocks (12 direct, plus single, double, and triple indirect). Inodes do not contain filenames; directory entries map names to inode numbers.

Indirect blocks are regular data blocks that hold additional block pointers, enabling files larger than the direct‑pointer limit. A typical 4 KiB block can hold 512 4‑byte pointers, allowing a single file to address 12 + 512 = 524 KiB of data blocks, with further levels for even larger files.

Fragmentation

Older PC filesystems (FAT, NTFS) suffer from severe fragmentation, degrading performance. EXT’s allocation policies greatly reduce fragmentation, and when it occurs, its impact is minimal.

Fragmentation can be inspected with

fsck -n

. The author’s workstation shows only ~1.5 % fragmentation. Theoretical calculations using a 300 GB Western Digital drive (2 ms average seek) suggest that modern EXT filesystems experience negligible performance loss due to fragmentation.

Tools such as

e4defrag

can defragment EXT4 filesystems, but they work only on EXT4 and have limitations. Full defragmentation typically requires moving all files off the filesystem and back.

Conclusion

For over two decades, EXT filesystems have been the default on many Linux distributions, offering stability, high capacity, reliability, and good performance with minimal maintenance. While other filesystems exist, EXT4 remains the recommended choice for most Linux systems unless a compelling reason dictates otherwise.