ext4 File System on Linux

Learn how ext4 works, evolved from ext2 and ext3, and improves Linux storage with journaling, extents, allocation, scalability, and recovery tools.

ext4, also called the fourth extended file system or ext4fs, is a native Linux disk file system. It organizes files, directories, metadata, and free space on a partition or other block device. It is commonly used for Linux operating-system files, applications, and user data.

This lesson covers ext4's relationship to ext2 and ext3, reliability features, capacity, performance, and basic administration. Before practicing, understand Linux block devices and partitions, mount points, sudo, and the difference between a storage device, partition, and file system. See the Linux fundamentals material for related command-line concepts.

What ext4 Is

Ext4 belongs to the extended-file-system family:

ext2 is an earlier extended Linux file system without a journal.
ext3 added journaling while retaining much of the ext2 design.
ext4 extends the family with features such as extents, improved allocation, larger scale, and more efficient maintenance.

A file system is created on a partition, logical volume, or another block device. Linux then mounts it at a directory such as /, /home, or /mnt/data. Ext4 is a general-purpose choice for local Linux storage, but no file system is best for every workload.

How ext2, ext3, and ext4 Relate

File system	Journaling	Extent support	Allocation behavior	Directory scalability	Typical use and compatibility notes
ext2	No journal	Traditional block mapping	Older allocation design	Less capable than later improvements	Useful where journaling is not wanted; commonly readable by ext-family tools.
ext3	Yes	Primarily ext2-style mapping	Improved reliability over ext2	Better than ext2 in common deployments	Journaling predecessor to ext4; older systems may not understand ext4-only features.
ext4	Yes	Yes	Delayed and multiblock allocation, commonly with extents	Indexed directories and larger practical scale	General-purpose Linux file system; compatibility depends on enabled features, kernel support, and tools.

Modern ext4 kernels and e2fsprogs tools can commonly inspect or work with ext2 and ext3 file systems. The reverse is not automatically safe: an ext3-era environment may fail to mount an ext4 file system after ext4-specific features are enabled. Converting or changing features requires a backup and validation of the target kernel and utilities. File-system names alone do not guarantee compatibility.

Journaling and Reliability

A journal is a log of file-system updates. Before changes to important file-system metadata are fully committed to their normal locations, the changes can be recorded in the journal. After an unclean shutdown, the system can replay pending journal transactions rather than reconstructing every metadata structure from scratch.

Journaling primarily protects file-system metadata. It does not automatically mean that every file's contents are logged before they reach disk. Ext4 commonly offers these data modes:

Mode	Behavior	Trade-off
`data=journal`	File data and metadata are written through the journal.	Stronger ordering and recovery characteristics, but more writing and lower performance.
`data=ordered`	Metadata is journaled, and associated data is written before the metadata transaction is committed.	Useful balance of reliability and performance; it does not journal all file contents.
`data=writeback`	Metadata is journaled with weaker ordering between data and metadata.	May improve performance, but after a crash an older or unrelated block's contents could be exposed in a file.

Journal replay can restore consistent metadata quickly, but it is not the same as a complete integrity check. Hardware errors, damaged metadata, or corruption outside the journal may still require an offline e2fsck check.

Key ext4 Features and Their Effects

Feature	What it changes	Primary benefit	Trade-off or caveat
Extents	Represent contiguous block ranges with mapping records.	Less metadata overhead and better large-file allocation.	Older ext2/ext3-only environments may not understand them.
Persistent preallocation	Reserves real disk blocks before file data is written.	Predictable space for databases, virtual-machine images, and media capture.	Reserved blocks consume capacity immediately.
Delayed allocation	Defers physical block selection until writeback.	More information is available for contiguous allocation decisions.	Data is not necessarily placed immediately; behavior depends on workload and flushing.
Multiblock allocator	Requests and allocates multiple blocks in one operation.	Favors contiguous placement and reduces fragmentation.	Benefits vary with free space and write patterns.
Directory indexing	Uses an index for directory entries.	Faster lookup in directories containing many files or subdirectories.	It does not make directory capacity infinite; structures and system resources still limit it.
Journal	Records metadata transactions for recovery.	Shorter recovery after an unclean shutdown and less metadata inconsistency.	Uses storage and can add write overhead.

Extent-Based Storage

An extent is a metadata record describing a contiguous range of physical blocks. Instead of recording a separate pointer for every block in a large file, ext4 can describe a run with one extent record.

For example, a file occupying blocks 10,000 through 10,999 can be represented as one range when those blocks are contiguous. This reduces inode and mapping metadata overhead, especially for large files, and gives the allocator a structure that works well with contiguous placement. Extents do not eliminate fragmentation, but they can reduce it in common workloads and make large-file allocation more efficient.

Persistent Preallocation and Sparse Files

Persistent preallocation reserves actual disk blocks for a file before all of its contents are written. It is useful for database files, virtual-machine disk images, video or audio capture, and applications that need predictable available space.

fallocate -l 10G database.img
ls -lh database.img
du -h database.img

Compare this with a sparse file. A sparse file has logical regions called holes that have no physical blocks allocated until data is written there:

truncate -s 10G sparse.img
ls -lh sparse.img
du -h sparse.img

ls -lh reports apparent file length, while du -h reports allocated disk usage. Preallocation consumes capacity even if the file has not received data. Sparse files can appear large while initially consuming little space, so an application writing into the holes can unexpectedly exhaust the volume.

Directory Scalability

Ext4 supports large directory trees and large numbers of entries and subdirectories. Directory indexing organizes directory entries into an indexed structure, making lookups more efficient than scanning every entry in a large directory.

There is no practical guarantee that a directory is literally unlimited. Limits depend on block size, directory structures, inode and block availability, kernel behavior, and system resources. Applications that create millions of files may still benefit from sharding data across multiple directories.

Checking, Recovery, and Maintenance

fsck is the general file-system check and repair process. e2fsck is the ext2/ext3/ext4 utility used to detect and repair structural problems. Ext4 can make maintenance faster through features such as uninitialized block groups, which avoid unnecessary initialization work, and journal-assisted recovery after a crash.

Journal replay is a targeted recovery operation, not a full examination of every file-system structure. Run a complete check only when the file system is unmounted or from an appropriate offline recovery environment. Do not repair a normally mounted writable root or data file system.

sudo e2fsck -f /dev/sdXN

Safety rule: Replace /dev/sdXN only after identifying the correct device and confirming that it is not mounted. Repair operations can cause data loss when used on the wrong device or an active writable file system.

Timestamps and Metadata

Common file timestamps include:

Access time (atime): when file data was last read.
Modification time (mtime): when file contents were last changed.
Change time (ctime): when inode metadata changed, such as permissions or ownership. It is not creation time.
Creation time: a birth-time value where supported by the kernel, file system, tools, and application APIs.

Ext4 expands timestamp range and precision compared with older extended-file-system formats. What users can see, and when timestamps change, depends on kernel support, user-space tools, mount options such as access-time policies, and the APIs used by applications.

Names, Files, and Capacity

Item	Commonly cited value	What affects the effective limit	Important clarification
Filename component	255 bytes	Encoding, directory-entry rules, and implementation details.	This is one component such as `report.txt`, not the entire path.
Maximum file size	Often documented as up to 16 TB	Block size, feature flags, kernel and userspace versions, architecture, and implementation.	Documentation figures are not a promise that every configuration supports the same value.
File-system size	Often documented as up to 1 EB	Block size, layout, feature flags, software versions, architecture, and available device support.	Practical deployments can have lower limits.

A byte is eight bits. Storage vendors commonly use decimal units: 1 TB = 10¹² bytes and 1 EB = 10¹⁸ bytes. Operating systems and tools may use binary units: 1 TiB = 2⁴⁰ bytes and 1 EiB = 2⁶⁰ bytes. Always check whether a displayed value is decimal or binary.

Performance Characteristics

Ext4 performance is the result of several interacting choices. Delayed allocation lets the system wait for more write information before choosing blocks. The multiblock allocator can request ranges at once, and extents can describe those ranges efficiently. Directory indexing improves lookup in large directories. Journaling improves recovery but introduces additional writes, with the selected data mode affecting both ordering and performance.

Actual results depend on workload, storage hardware, free-space fragmentation, mount options, memory pressure, and application write patterns. Ext4 is not universally fastest: databases, large sequential files, many small files, snapshots, and other workloads can favor different designs or tuning choices.

Basic ext4 Administration

Identify a device and its file system

lsblk -f
sudo blkid /dev/sdXN

lsblk -f lists block devices, file-system types, labels, UUIDs, and mount points. blkid reports identifying metadata for a selected device. A UUID is a unique file-system identifier commonly used for persistent mounting.

Create and label an ext4 file system

sudo mkfs.ext4 -L data /dev/sdXN

Destructive command: Formatting destroys the existing file-system contents on the target. Confirm the device with lsblk and backups before running mkfs.ext4.

Mount an ext4 file system

sudo mkdir -p /mnt/data
sudo mount /dev/sdXN /mnt/data
findmnt /mnt/data

Configure persistent mounting

sudo blkid /dev/sdXN
UUID=example-uuid /mnt/data ext4 defaults 0 2

The second line is an illustrative /etc/fstab entry. Replace the example UUID with the actual value, ensure /mnt/data exists, and choose options appropriate for the system. Test carefully with sudo mount -a before rebooting.

Inspect the superblock and features

A superblock is core file-system metadata describing layout, size, state, and enabled features. An ext4 block group is a subdivision containing related allocation and metadata structures.

sudo tune2fs -l /dev/sdXN
sudo dumpe2fs -h /dev/sdXN

These commands help identify the file-system state, UUID, block size, feature flags, journal information, and other layout details. Use the output when investigating compatibility problems.

Practical Scenarios

Creating a general-purpose data partition

Identify the intended partition with lsblk -f.
Confirm that it contains no data you need.
Create and label the file system with mkfs.ext4.
Mount it and verify the result with findmnt or df -T.

Recovering after an unclean shutdown

The kernel may replay the ext4 journal during mounting. If errors remain, the volume is reported as damaged, or storage logs show I/O problems, arrange an offline check and run e2fsck. Investigate hardware health and kernel logs as well; a file-system repair cannot fix a failing disk.

Investigating automatic-mount failures

Compare the UUID in /etc/fstab with blkid.
Check that the mount-point directory exists.
Verify the type is ext4 and options are valid.
Test with sudo mount -a and review system logs.
If corruption is indicated, unmount the volume and check it offline.

Investigating compatibility failures

If a system reports an unknown ext4 feature or cannot mount a volume, inspect features with tune2fs or dumpe2fs. Verify kernel and e2fsprogs support before changing features. If the target environment is too old, use a supported environment or back up the data and recreate the file system with compatible options.

Exam-Relevant Notes

Ext4 is the fourth extended Linux file system and follows ext2 and ext3.
Ext2 lacks journaling; ext3 and ext4 provide journaling.
Metadata journaling is not the same as journaling file contents.
An extent maps a contiguous range of blocks with one record.
Persistent preallocation uses real blocks; sparse-file holes do not.
Directory indexing improves large-directory lookups but does not make directories infinite.
Journal replay is not a complete e2fsck integrity check.
Compatibility is feature-, kernel-, tool-, and conversion-method-dependent.
Never format or repair a device without confirming its identity and mount state.