Chapter 6. The Ext4 File System
fsck. For more information, see Chapter 5, The Ext3 File System.
- Main Features
- Ext4 uses extents (as opposed to the traditional block mapping scheme used by ext2 and ext3), which improves performance when using large files and reduces metadata overhead for large files. In addition, ext4 also labels unallocated block groups and inode table sections accordingly, which allows them to be skipped during a file system check. This makes for quicker file system checks, which becomes more beneficial as the file system grows in size.
- Allocation Features
- The ext4 file system features the following allocation schemes:
Because of delayed allocation and other performance optimizations, ext4's behavior of writing files to disk is different from ext3. In ext4, when a program writes to the file system, it is not guaranteed to be on-disk unless the program issues an
- Persistent pre-allocation
- Delayed allocation
- Multi-block allocation
- Stripe-aware allocation
fsync()call afterwards.By default, ext3 automatically forces newly created files to disk almost immediately even without
fsync(). This behavior hid bugs in programs that did not use
fsync()to ensure that written data was on-disk. The ext4 file system, on the other hand, often waits several seconds to write out changes to disk, allowing it to combine and reorder writes for better disk performance than ext3.
WarningUnlike ext3, the ext4 file system does not force data to disk on transaction commit. As such, it takes longer for buffered writes to be flushed to disk. As with any file system, use data integrity calls such as
fsync()to ensure that data is written to permanent storage.
- Other Ext4 Features
- The ext4 file system also supports the following:
- Extended attributes (
xattr) — This allows the system to associate several additional name and value pairs per file.
- Quota journaling — This avoids the need for lengthy quota consistency checks after a crash.
NoteThe only supported journaling mode in ext4 is
- Subsecond timestamps — This gives timestamps to the subsecond.
6.1. Creating an Ext4 File System
mkfs.ext4command. In general, the default options are optimal for most usage scenarios:
mkfs.ext4 command output
~]# mkfs.ext4 /dev/sdb1 mke2fs 1.41.12 (17-May-2010) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 245280 inodes, 979456 blocks 48972 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=1006632960 30 block groups 32768 blocks per group, 32768 fragments per group 8176 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736 Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 20 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override.
mkfs.ext4chooses an optimal geometry. This may also be true on some hardware RAIDs which export geometry information to the operating system.
mkfs.ext4(that is, extended file system options) with the following sub-options:
- Specifies the RAID chunk size.
- Specifies the number of data disks in a RAID device, or the number of stripe units in the stripe.
valuemust be specified in file system block units. For example, to create a file system with a 64k stride (that is, 16 x 4096) on a 4k-block file system, use the following command:
mkfs.ext4 -E stride=16,stripe-width=64 /dev/device
tune2fsto enable some ext4 features on ext3 file systems, and to use the ext4 driver to mount an ext3 file system. These actions, however, are not supported in Red Hat Enterprise Linux 6, as they have not been fully tested. Because of this, Red Hat cannot guarantee consistent performance and predictable behavior for ext3 file systems converted or mounted in this way.