The ext4 or fourth extended filesystem is a journaling file system for Linux, developed
as the successor to ext3.
History ext4 was born as a series of backward compatible
extensions to ext3, many of them originally developed by Cluster File Systems for the
Lustre file system between 2003 and 2006, meant to extend storage limits and add other
performance improvements.
However, other Linux kernel developers opposed accepting extensions to ext3 for stability
reasons, and proposed to fork the source code of ext3, rename it as ext4, and perform all
the development there, without affecting the current ext3 users.
This proposal was accepted, and on 28 June 2006, Theodore Ts'o, the ext3 maintainer,
announced the new plan of development for ext4.
A preliminary development version of ext4 was included in version 2.6.19 of the Linux
kernel.
On 11 October 2008, the patches that mark ext4 as stable code were merged in the Linux
2.6.28 source code repositories, denoting the end of the development phase and recommending
ext4 adoption.
Kernel 2.6.28, containing the ext4 filesystem, was finally released on 25 December 2008.
On 15 January 2010, Google announced that it would upgrade its storage infrastructure
from ext2 to ext4.
On 14 December 2010, they also announced they would use ext4, instead of YAFFS, on Android
2.3.
Features Large file system
The ext4 filesystem can support volumes with sizes up to 1 exbibyte and files with sizes
up to 16 tebibytes.
However, Red Hat recommends using XFS instead of ext4 for volumes larger than 100 TB.
Extents Extents replace the traditional block mapping
scheme used by ext2 and ext3.
An extent is a range of contiguous physical blocks, improving large file performance and
reducing fragmentation.
A single extent in ext4 can map up to 128 MiB of contiguous space with a 4 KiB block
size.
There can be four extents stored in the inode.
When there are more than four extents to a file, the rest of the extents are indexed
in an HTree.
Backward compatibility ext4 is backward compatible with ext3 and
ext2, making it possible to mount ext3 and ext2 as ext4.
This will slightly improve performance, because certain new features of ext4 can also be used
with ext3 and ext2, such as the new block allocation algorithm.
ext3 is partially forward compatible with ext4.
That is, ext4 can be mounted as ext3.
However, if the ext4 partition uses extents, then the ability to mount as ext3 is lost.
Persistent pre-allocation ext4 can pre-allocate on-disk space for a
file.
To do this on most file systems, zeros would be written to the file when created.
In ext4 fallocate(), a new system call in the Linux kernel, can be used.
The allocated space would be guaranteed and likely contiguous.
This situation has applications for media streaming and databases.
Delayed allocation ext4 uses a performance technique called allocate-on-flush
also known as delayed allocation.
That is, ext4 delays block allocation until it writes data to disk.
Delayed allocation improves performance and reduces fragmentation by using the actual
file size to improve block allocation.
Increasing the 32,000 subdirectory limit In ext3 a directory can have at most 32,000
subdirectories.
Ext4 allows an unlimited number of subdirectories.
To allow for larger directories and continued performance, ext4 turns on HTree indexes by
default.
This feature is implemented in Linux 2.6.23.
In ext3 HTrees can be used by enabling the dir_index feature.
Journal checksumming ext4 uses checksums in the journal to improve
reliability, since the journal is one of the most used files of the disk.
This feature has a side benefit: it can safely avoid a disk I/O wait during journaling, improving
performance slightly.
Journal checksumming was inspired by a research paper from the University of Wisconsin, titled
IRON File Systems, with modifications within the implementation of compound transactions
performed by the IRON file system.
Faster file system checking In ext4 unallocated block groups and sections
of the inode table are marked as such.
This enables e2fsck to skip them entirely and greatly reduces the time it takes to check
the file system.
Linux 2.6.24 implements this feature.
Multiblock allocator When ext3 appends to a file, it calls the
block allocator, once for each block.
Consequently, if there are multiple concurrent writers, files can easily become fragmented
on disk.
However, ext4 uses delayed allocation which allows it to buffer data and allocate groups
of blocks.
Consequently the multiblock allocator can make better choices about allocating files
contiguously on disk.
The multiblock allocator can also be used when files are opened in O_DIRECT mode.
This feature does not affect the disk format.
Improved timestamps As computers become faster in general and
as Linux becomes used more for mission-critical applications, the granularity of second-based
timestamps becomes insufficient.
To solve this, ext4 provides timestamps measured in nanoseconds.
In addition, 2 bits of the expanded timestamp field are added to the most significant bits
of the seconds field of the timestamps to defer the year 2038 problem for an additional
204 years.
ext4 also adds support for date-created timestamps.
But, as Theodore Ts'o points out, while it is easy to add an extra creation-date field
in the inode, it is more difficult to modify or add the necessary system calls, like stat()
and the various libraries that depend on them.
These changes would require coordination of many projects.
So even if ext4 developers implement initial support for creation-date timestamps, this
feature will not be available to user programs for now.
Criticism In 2008, the principal developer of the ext3
and ext4 file systems, Theodore Ts'o, stated that although ext4 has improved features,
it is not a major advance, it uses old technology, and is a stop-gap.
Ts'o believes that Btrfs is the better direction because "it offers improvements in scalability,
reliability, and ease of management".
Btrfs also has "a number of the same design ideas that reiser3/4 had".
Delayed allocation and potential data loss Because delayed allocation changes the behavior
that programmers have been relying on with ext3, the feature poses some additional risk
of data loss in cases where the system crashes or loses power before all of the data has
been written to disk.
Due to this, ext4 in kernel versions 2.6.30 and later automatically handles these cases
as ext3 does.
The typical scenario in which this might occur is a program replacing the contents of a file
without forcing a write to the disk with fsync.
There are two common ways of replacing the contents of a file on Unix systems:
fd=open("file", O_TRUNC); write(fd, data); close(fd);
In this case, an existing file is truncated at the time of open, then new data is written
out.
Since the write can take some time, there is an opportunity of losing contents even
with ext3, but usually very small.
However, because ext4 can delay writing file data for a long time, this opportunity is
much greater.
There are several problems that can arise: If the write does not succeed, then both the
original version and the new version of the file will be lost, and the file may be corrupted
because only a part of it has been written.
If other processes access the file while it is being written, they see a corrupted version.
If other processes have the file open and do not expect its contents to change, those
processes may crash.
One notable example is a shared library file which is mapped into running programs.
Because of these issues, often the following idiom is preferred over the one above:
fd=open("file.new"); write(fd, data); close(fd); rename("file.new", "file");
A new temporary file is created, which initially contains the new contents.
Then the new file is renamed over the old one.
Replacing files by the "rename" call is guaranteed to be atomic by POSIX standards – i.e. either
the old file remains, or it's overwritten with the new one.
Because the ext3 default "ordered" journaling mode guarantees file data is written out on
disk before metadata, this technique guarantees that either the old or the new file contents
will persist on disk.
ext4's delayed allocation breaks this expectation, because the file write can be delayed for
a long time, and the rename is usually carried out before new file contents reach the disk.
Using fsync more often to reduce the risk for ext4 could lead to performance penalties
on ext3 filesystems mounted with the data=ordered flag.
Given that both file systems will be in use for some time, this complicates matters for
end-user application developers.
In response, ext4 in Linux kernels 2.6.30 and newer detect the occurrence of these common
cases and force the files to be allocated immediately.
For a small cost in performance, this provides semantics similar to ext3 ordered mode and
increases the chance that either version of the file will survive the crash.
This new behavior is enabled by default, but can be disabled with the "noauto_da_alloc"
mount option.
The new patches have become part of the mainline kernel 2.6.30, but various distributions chose
to backport them to 2.6.28 or 2.6.29.
For instance, Ubuntu made them part of the 2.6.28 kernel in version 9.04.
These patches don't completely prevent potential data loss or help at all with new files.
The only way to be safe is to write and use software that does fsync when it needs to.
Performance problems can be minimized by limiting crucial disk writes that need fsync to occur
less frequently.
Compatibility with Windows and Macintosh ext4 does not yet have as much support as
ext2 and ext3 on non-Linux operating systems.
ext2 and ext3 have stable drivers such as Ext2IFS, which are not yet available for ext4.
It is possible to create compatible ext4 filesystems for use in Windows by disabling the extents
feature, and sometimes specifying an inode size.
Another option for using ext4 in Windows is to use Ext2Fsd, an open-source driver that,
like Ext2IFS, supports writing in ext4 partitions where extents have been disabled.
Viewing and copying files from ext4 to Windows, even with extents enabled, is also possible
with the Ext2Read software.
More recently Paragon released its ExtFS for Windows which allows read/write capabilities
for ext24.
Mac OS X has full ext24 read/write capability through the Paragon ExtFS software, which
is a commercial product.
Free software such as ext4fuse has only read-only support with limited functionality.
See also List of file systems
Comparison of file systems Btrfs
Reiser4 ZFS
Ext2Fsd References
External links Theodore Ts'o's discussion on ext4, 29 June
2006 First benchmarks of ext4, 21 Oct 2006
"ext4 online defragmentation" "The new ext4 filesystem: current status and
future plans" Kernel Log: Ext4 completes development phase
as interim step to btrfs, 17 October 2008 "Ext4 block and inode allocator improvements"
“Ext4: The Next Generation of Ext2/3 Filesystem” Ext4 Wiki
Ext4 wiki at kernelnewbies.org Native Windows port of Ext4 and other FS in
CROSSMETA Ext2read A windows application to read/copy
ext2ext4 files with extent and LVM2 support.
Ext2Fsd Open source ext2ext4 read/write file system driver for Windows.
ext4 is supported from version 0.50 onwards Ext4fuse Open source read-only ext4 driver
for FUSE.