Ext4 Filesystem

This article will provide a brief introduction to Linux File System Ext4, the successor to Linux File System Ext3. Several tips regarding usage as well as additional links will be provided.


The ext3 source was forked and developed independently, in order to correct several existing limitations of the previous Ext2 and Ext3 file systems in the future. Ext4 has been accepted into the Linux kernel as of Kernel version 2.6.19 and finally declared stable as of Kernel version 2.6.28.

Current distribution files, like RedHat Enterprise Linux 6 (RHEL), Debian 6.0 (Squeeze) or Ubuntu 10.10 (Maverick Meerkat) provide stable Ext4 support and use it as the default file system, in some cases.


  • Improved performance through:
    • Multi-block allocation
    • Extent-based block mapping
    • Delayed allocation
    • Stripe-aware allocation
  • Improved file security through:
    • Write barriers
  • Time stamps use the nanosecond range instead of the second range
  • Increased e2fsck speed
  • Unlimited number of sub-directories (32,000 sub-directory under a directory under Ext3)
  • Journalized quota data, whereby a quota check will not be performed after a system crash

You can find additional details regarding these advantages in a white paper from Red Hat [1].

Compatibility with Ext3

Because there have been many changes in comparison with Ext3, migration to Ext4 is not as easy as from Ext2 to Ext3.

To take full advantage of the Ext4 file system, Red Hat recommends backing all of the data up for RHEL 6, re-creating the Ext4 file system and copying the data into the new Ext4 file system.

The Ext4 driver does support mounting an Ext3 file system, however only with limited functionality. On the other hand, as soon as one uses extent-based mapping, mounting an Ext4 file system as an Ext3 file system becomes impossible.

SSD Optimizations

ATA Trim

Ext4 supports ATA Trim for solid state drives (SSDs):

  • Online discard from Kernel 2.6.33
    • The -o discard mount option (for example mount -o discard /dev/sdb1 /mnt/. For permanent activation, the option must be entered in /etc/fstab, because the discard capability is deactivated by default)
  • Batched discard from Kernel 2.6.37
  • Accelerated batched discard from Kernel 3.1
  • Pre-discard during formatting from mke2fs 1.41.10
    • Extract from the man page for mke2fs: -E discard: Attempt to discard blocks at mkfs time (discarding blocks initially is useful on solid state devices and sparse / thin-provisioned storage). When the device advertises that discard also zeroes data (any subsequent read after the discard and before write returns zero), then mark all not-yet-zeroed inode tables as zeroed. This significantly speeds up file system initialization. This is set as default.
    • In our test, we observed significantly different time requirements for the discard operation during formatting. However, significant effects were not caused by discard also zeroes data (regarding this, see ATA Trim Performance).
    • With discard also zeroes data, hdparm -I displayed Deterministic read ZEROs after TRIM (or deterministic read data after TRIM). The following example shows an OCZ Vertex 3 SSD and an Intel 320 Series SSD:
[root@fedora15 ~]# hdparm -V
hdparm v9.43
[root@node5 ~]# hdparm -I /dev/sda | grep 'Model\|TRIM'
	Model Number:       OCZ-VERTEX3                             
	   *	Data Set Management TRIM supported (limit 1 block)
	   *	Deterministic read data after TRIM
[root@node5 ~]# hdparm -I /dev/sdb | grep 'Model\|TRIM'
	Model Number:       INTEL SSDSA2CW16xxx                     
	   *	Data Set Management TRIM supported (limit 8 blocks)
	   *	Deterministic read ZEROs after TRIM
[root@node5 ~]# 

File System Journal: Yes or No?

Not using the Ext4 file system journal can increase file system performance, is however connected with disadvantages when the shutdown procedure is not completely clean (such as during a power failure). Theodore Tso, an Ext4 file system developer, determined in tests that the performance disadvantages caused by journaling were between four and twelve percent. Therefore, the journal should be used. Not using the atime journaling would be a more recommendable way of increasing performance.


Using the noatime mount option improves performance when reading.

Should stride and stripe-width Parameters be used?

There are a number of different recommendations for the stride and stripe-width parameters for using SSDs under Ext4.

If certain values really do provide a benefit cannot be determined with certainty at this time. Individualized tests with the respective SSD would be required for making a determination.

Lazy Initialization

When creating an Ext4 file system, the existing regions of the inode tables must be cleaned (overwritten with nulls, or "zeroed"). The "lazyinit" feature should significantly accelerate the creation of a file system, because it does not immediately initialize all inode tables, initializing them gradually instead during the initial mounting process in background (from Kernel version 2.6.37). Regarding this see the extracts from the mkfs.ext4 man pages:

If enabled and the uninit_bg feature is enabled, the inode table will not be fully initialized by mke2fs. This speeds up file system initialization noticeably, but it requires the kernel to finish initializing the file system in the background when the file system is first mounted. If the option value is omitted, it defaults to 1 to enable lazy inode table zeroing.

One should be careful when testing the performance of a freshly created file system. The "lazy initialization" feature may write a lot of information to the hard disk after the initial mounting and thereby invalidate the test results. At first, the "ext4lazyinit" kernel process writes at up to 16,000kB/s to the device and thereby uses a great deal of the hard disk’s bandwidth (see also I/O Statistics by Process). In order to prevent lazy initialization, advanced options are offered by the mkfs.ext4 command:

mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/mapper/fc-root

By specifying these options, the inodes and the journal will be initialized immediately during creation.

Potential Problems

Poor Performance due to Write Barriers

The integrity of the file system can be guaranteed by write barriers, if the hard disk uses a volatile cache and the contents of the cache are lost due to a power failure. Thereby, data security is improved, however at the price of a small performance disadvantage. By default, write barriers are activated, however they can be deactivated with the nobarrier file system option. However, this is only recommended when the write cache for your RAID array has been secured using a battery backup unit, zero maintenance cache or similar measure.

Data Loss with Applications that do not use fsync() correctly

When Ext4 was first introduced with Linux distributions, notifications about sometimes massive data losses began to appear.

The reason for this is delayed allocation, which first allocated the necessary storage space up to 60 seconds later. Thereby, file renaming entered the scenario, for example, so that the metadata properly represented the rename process, but the actual data had not yet been written. The file name pointed to a 0 byte file thereby. However, this only occurs when an application has not properly used the fsync() feature. According to developer Theodore Ts'o, Ext4 precisely implements the POSIX standard for file operations. The problem is that the "secure" behavior of Ext3 was undesirable, however was considered a given by many application developers due to its wide distribution.

Initially the "alloc_on_commit" mode was introduced as a workaround, which was replaced by the "auto_da_alloc" mode shortly thereafter in Kernel 2.6.30 (see Kernel Commit ). Thereby, attempts will be made to detect and avoid frequently occurring cases for potential data loss. This mode became the new default mode, but can be deactivated by "noauto_da_alloc".

In general, applications should improve their compliance with the POSIX standard in the future and use fsync() in the required positions. Ext4 has been subsequently optimized for this problem based on the prior history of Ext3. Other file systems using delayed allocation (such as XFS or Btrfs) do not take this into consideration.


Comments powered by CComment