name	ext4
full name	Fourth extended file system
developer	Mingming Cao, Andreas Dilger, Alex Zhuravlev (Tomas), Dave Kleikamp, Theodore Ts'o, Eric Sandeen, Sam Naghshineh, others
introduction os	Linux 2.6.28, 2.6.19
introduction date	Stable: 21 October 2008Unstable: 10 October 2006
partition id	0x83 (MBR)EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (GPT)
directory struct	Linked list, hashed B-tree
file struct	Extents/Bitmap
bad blocks struct	Table
max filename size	256 bytes
max files no	4 billion (specified at filesystem creation time)
max volume size	1 EiB
max file size	16 TiB (for 4k block filesystem)
filename character set	All bytes except NULL ('\0') and '/'
dates recorded	modification (mtime), attribute modification (ctime), access (atime), delete (dtime), create (crtime)
date range	14 December 1901 - 25 April 2514
date resolution	Nanosecond
forks streams	No
attributes	extents, noextents, mballoc, nomballoc, delalloc, nodelalloc, datajournal, dataordered, datawriteback, commitnrsec, orlov, oldalloc, user_xattr, nouser_xattr, acl, noacl, bsddf, minixdf, bh, nobh, journal_dev
file system permissions	POSIX
compression	No
encryption	No
single instance storage	No
os	LinuxWindows (using ext2fsd) }}

The ext4 or fourth extended filesystem is a journaling file system for Linux, developed as the successor to ext3.

It 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 do 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 December 14, 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 (EiB) and files with sizes up to 16 tebibytes (TiB). The current e2fsprogs can only handle a filesystem of 16 TiB, but support for larger filesystems is under development.

;Extents :Extents replace the traditional block mapping scheme used by ext2/3 filesystems. 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 4 extents stored in the inode. When there are more than 4 extents to a file, the rest of the extents are indexed in an Htree.

;Backward compatibility :The ext4 filesystem is backward compatible with ext3 and ext2, making it possible to mount ext3 and ext2 filesystems 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.

:The ext3 file system is partially forward compatible with ext4, that is, an ext4 filesystem can be mounted as an ext3 partition (using "ext3" as the filesystem type when mounting). However, if the ext4 partition uses extents (a major new feature of ext4), then the ability to mount the file system as ext3 is lost.

;Persistent pre-allocation :The ext4 filesystem allows for pre-allocation of on-disk space for a file. The current method for this on most file systems is to write the file full of 0s to reserve the space when the file is created. This method is no longer required for ext4; instead, a new fallocate() system call was added to the Linux kernel for use by filesystems, including ext4 and XFS, that have this capability. The space allocated for files such as these would be guaranteed and would likely be contiguous. This has applications for media streaming and databases.

;Delayed allocation :Ext4 uses a filesystem performance technique called allocate-on-flush, also known as ''delayed allocation''. It consists of delaying block allocation until the data is going to be written to the disk, unlike some other file systems, which may allocate the necessary blocks before that step. This improves performance and reduces fragmentation by improving block allocation decisions based on the actual file size.

;Break 32,000 subdirectory limit :In ext3 the number of subdirectories that a directory can contain is limited to 32,000. This limit has been raised to 64,000 in ext4, and with the "dir_nlink" feature it can go beyond this (although it will stop increasing the link count on the parent). To allow for continued performance given the possibility of much larger directories, Htree indexes (a specialized version of a B-tree) are turned on by default in ext4. This feature is implemented in Linux kernel 2.6.23. Htree is also available in ext3 when the dir_index feature is enabled.

;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 the journaling process, improving performance slightly. The technique of journal checksumming was inspired by a research paper from the University of Wisconsin titled ''IRON File Systems'' (specifically, section 6, called "transaction checksums") with modifications within the implementation of compound transactions performed by the IRON file system (originally proposed by Sam Naghshineh in the RedHat summit).

;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 on a check and greatly reduces the time it takes to check a file system of the size ext4 is built to support. This feature is implemented in version 2.6.24 of the Linux kernel.

;Multiblock allocator :When a file is being appended to, ext3 calls the block allocator once for each block individually; with multiple concurrent writers, files can easily become fragmented on disk. With delayed allocation, however, ext4 buffers up a larger amount of data, and then allocates a group of blocks in a batch. This means that the allocator has more information about what's being written and can make better choices for allocating files contiguously on disk. The multiblock allocator is used when delayed allocation is enabled for a file system, or 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 (thus technically enabling support for date-created timestamps in ext4), it is more difficult to modify or add the necessary system calls, like stat() (which would probably require a new version), and the various libraries that depend on them (like glibc). 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.

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 detects these cases and reverts to the old behavior.

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 (due to O_TRUNC flag), 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 allocating file data for a long time, this opportunity is much greater. : There are several problems with this approach: :# If the write does not succeed (which may be due to error conditions in the writing program, or due to external conditions such as a full disk), 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 above one:

fd=open("file.new"); write(fd, data); close(fd); rename("file.new", "file");

: A new temporary file ("file.new") 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" journalling 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 (the default on most Linux distributions). 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 ("Jaunty Jackalope").

These patches don't completely prevent potential data loss or help at all with new files. No other filesystem is perfect in terms of data loss either, although the probability of data loss is lower on ext3. 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.

See also

List of file systems

Comparison of file systems

Btrfs

Reiser4

ZFS

References

External links

Theodore Ts'o's discussion on ext4, 29 June 2006

First benchmarks of ext4, 21 Oct 2006

"ext4 online defragmentation" (materials from Ottawa Linux Symposium 2007)

"The new ext4 filesystem: current status and future plans" (materials from Ottawa Linux Symposium 2007)

Kernel Log: Ext4 completes development phase as interim step to btrfs, 17 October 2008

"Ext4 block and inode allocator improvements" (materials from Ottawa Linux Symposium 2008)

“Ext4: The Next Generation of Ext2/3 Filesystem”

Ext4 (and Ext2/Ext3) Wiki

Ext4 wiki at kernelnewbies.org

Ext2read A windows application to read/copy ext2/ext3/ext4 files with extent and LVM2 support.

Ext2Fsd Open source ext2/ext3/ext4 read/write file system driver for Windows. ext4 is supported from version 0.50 onwards

Ext4fuse Open source read-only ext4 driver for FUSE. (Supports Mac OS X 10.5 and later, using MacFuse)

Category:2008 software Category:Computer file systems Category:Disk file systems Category:Linux file systems

cs:Ext4 de:Ext4 es:Ext4 eo:Ext4 eu:Ext4 fr:Ext4 ko:Ext4 it:Ext4 nl:Ext4 ja:Ext4 no:Ext4 pl:Ext4 pt:Ext4 ro:Ext4 ru:Ext4 sk:Ext4 sv:Ext4 tr:Ext4 uk:Ext4 zh:Ext4