Ext4 – Fourth Extended File System

Ext4 – Fourth Extended File System

About Ext4
Developer
Mingming Cao, Andreas Dilger, Alex Tomas, Dave Kleikamp, Theodore Ts’o, Eric Sandeen, Sam Naghshineh, others.

Full Name
Fourth Extended File System

Introduced
Stable: October 21, 2008
Unstable: October 10, 2006 (Linux 2.6.19)

Structures
Directory Contents
Linked list, htree

File Allocation
Extents/Bitmap

Bad Blocks
Table

Limits
Max File Size
1 EiB (for 4k block filesystem)

Max Number Of Files
4 billion (specified at filesystem creation time)

Max Filename Length
256

Max Volume Size
1 EiB

Allowed Characters In Filenames
All bytes except NUL and ‘/’

Features
Datas Recorded
modification (mtime), attrbute modification (ctime), access (atime), delete (dtime), create (ctime)

Data Range
December 14, 1901 – April 25, 2514

Data Resolution
Nanosecond

Forks
No

Attributes
extents, noextents, mballoc, nomballoc, delalloc, nodelalloc, data=journal, data=ordered, data=writeback, commit=nrsec, orlov, oldalloc, user_xattr, nouser_xattr, acl, noacl, bsddf, minixdf, bh, nobh, journal_dev

File System Permissions
POSIX

Transparent Compression
No

Transparent Encryption
No

Single Instance Storage
No

Supported Operatring System
Linux

The Ext4 or Fourth Extended File System is a jouraled file system developed as the successor of Ext3. It was born as a series of backwards-compatible extensions to add to Ext3 64-bit storage limits and other performance improvements[1]. However, other Linux kernel developers opposed[2] accepting extensions to Ext3 for stability reasons, and proposed to fork the source code of Ext34, rename it as Ext4 and do all the development there without affecting the current Ext3 users This proposal was accepted, and on June 28, 2006 Theodore Ts’o, the Ext3 maintainer, announced[3] the new plan of development of Ext4. A preliminary development snapshot of Ext4 was included in version 2.6.19 of the Linux kernel. ON Oct 11, 2008 the patches[4] that mark Ext4 as stable code were merged in the Linux 2.6.28 source code repositories, marking the end of the development phase and recommending its adoption.

Contents
1. Features
1.1. Large File System
1.2. Extents
1.3. Backward Compatibility
1.4. Forward Compatibility
1.5. Persistent Pre-allocation
1.6. Delayed Aloocation
1.7. Break 32000 Subdirectory Limit
1.8. Journal Checksumming
1.9. Online defragmentaion
1.10. Faster File System Checking
1.11. Multiblock Allocator
1.12. Improved Timestamps
2. References
3. External Links

1. Features
1.1. Large File System
The Ext4 filesystem can support volumes with sizes up to 1 exabyte. Since Linux kernel version 2.6.25, it also supports files as large as the file system.

1.2. Extents
Extents are introduced to replace the traditional block mapping scheme used by Ext2/3 filesystems. A extent is a range of contiguous physical blocks, improving large file performance and reducing fragmentation. A single extent in Ext4 can map up to 128MiB of contiguous space with a 4KiB block size[5].

1.3. Backward Compatibility
The Ext4 filesystem is backward compatible with Ext3, making it possible to mount an Ext3 filesystem as Ext4 (using the “ext4dev” filesystem type, “Ext4” after final release).

1.4. Forward Compatibility
The Ext4 file system is forward compatible with Ext3, that is, it 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. Extents were enabled by default in the 2.6.23 kernel. Previously, the “extents” option was explicitly required (e.g. mount /dev/sda1 /mnt/point -t ext4dev -o extents).

1.5. Persistent Pre-allocation
The Ext4 filesystem allows for pre-allocation of on-disk space for a file. The current methodology for this on most file systems is to write the file full of 0’s to reserve the space when the file is created (although XFS has an ioctl to allow for true pre-allocation as well). This method would no longer be required for Ext4; instead, a new preallocate() system call was added for use by filesystems, including Ext4 and XFS, that have this capbility. The space allocated for files such as these would be guaranteed and would likely be contiguous. This has applications for media streaming and databases.

1.6. Delayed Allocation
Ext4 uses a filesystem performance technique called Allocate-on-flush, also know as delayed allocation. It consists in delaying block allocation unitl the data is going to be written to the disk, unlike other filesystems, which allocate the necessary blocks before of that step. This improves performance and reduces fragmentation by virtue of improving block allocation decisions based on the actual file size.

1.7. Break 32000 Subdirectory Limit
In Ext3 the number of subdirectory that a directory can contain is limited to 32000. This limit has been raised to 64000 in Ext4, and with the “dir_nlink” feature it can to 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 Btree) is turned on by default in Ext4. This feature is implemented in 2.6.23. htree is also available in Ext3 when the dir_index feature is enabled.

1.8. Journal Checksumming
Ext4 uses checksums in the journal to improve reliability, since the journal is one of the most used file of the disk. This feature has a side benefit; it can safely avoid a disk IO wait during the journaling process, improving performance slightly. The technique of journal checksumming was inspired by research from Wisconsin on IRON File Systems (Section 6, called “transaction checksums”)[6].

1.9. Online Defragmentation
Ext4 will eventually also have an online defragmenter. Even with the various techniques used to avoid it, a long lived file system does tend to become fragmented over time. Ext4 will have a tool which can defragment individual files or entire file systems.

1.10. 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 reduce 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.

1.11. Multiblock Allocator
Ext4 will have a multiblock allocator. This allows many blocks to be allocated to a file in single operation and therefore a better decision can be made on finding a chunk of free space where all the blocks can fit. The multiblock allocator is active when using O_DIRECT or if delayed allocation is on. This allows the file to have many dirty blocks submitted for writes at the same time, unlike the existing kernel mechanism of submitting each block to the filesystem separately for allocation.

1.12. Improved Timestamps
As computers become faster in general and specifically Linux becomes used more for mission critical applications, the granularity of second-based timestamps becomes insufficient. To solve this, ext4 will have timestamps measured in nanoseconds. This feature is currently implemented in 2.6.23. 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 500 years.

Support for date-created timestamps is added in ext4. But as Theodore Ts’o points out, while adding an extra creation date field in the inode is easy (thus technically enabling support for date-created timestamps in ext4), modifying or adding the necessary system calls, like stat() (which would probably require a new version), and the various libraries that depend on them (like glibc) is not trivial and would require the coordination of many different projects[7]. So even if ext4 developers implement initial support for creation date timestamps, this feature will not be available to user programs for now.[7]

2. References
1. https://ols2006.108.redhat.com/2007/Reprints/mathur-Reprint.pdf
2. LKML: Linus Torvalds: Re: [Ext2-devel] [RFC 0/13] extents and 48bit ext3
3. LKML: “Theodore Ts’o”: Proposal and plan for ext2/3 future development work
4. “ext4: Rename ext4dev to ext4”. Linus’ kernel tree. Retrieved on 2008-10-20.
5. “Ext4 overview”. Retrieved on 2008-01-15.
6. Vijayan Prabhakaran, et al. “IRON File Systems” (PDF). CS Dept, University of Wisconsin.
7. “Theodore Ts’o answer on creation time stamps for ext4”.

3. External Links

One thought on “Ext4 – Fourth Extended File System”

  1. I have been surfing on-line greater than three hours these days, yet I never discovered any attention-grabbing article
    like yours. It is lovely value sufficient
    for me. In my opinion, if all website owners and bloggers made
    excellent content as you probably did, the web will be a lot more helpful
    than ever before.

Leave a Reply

Your email address will not be published. Required fields are marked *