Redhat Ext4 File System Guide

⁠Chapter 6. The Ext4 File System

The ext4 file system is a scalable extension of the ext3 file system, which was the default file system of Red Hat Enterprise Linux 5. Ext4 is the default file system of Red Hat Enterprise Linux 6, and can support files and file systems up to 16 terabytes in size. It also supports an unlimited number of sub-directories (the ext3 file system only supports up to 32,000), though once the link count exceeds 65,000 it resets to 1 and is no longer increased.

Note

As with ext3, an ext4 volume must be umounted in order to perform an  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:

• Persistent pre-allocation
• Delayed allocation
• Multi-block allocation
• Stripe-aware allocation

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

Warning

Unlike 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.

  Note

  The only supported journaling mode in ext4 is  data=ordered (default).
• Subsecond timestamps — This gives timestamps to the subsecond.

⁠6.1. Creating an Ext4 File System

To create an ext4 file system, use the  mkfs.ext4 command. In general, the default options are optimal for most usage scenarios:

# mkfs.ext4 /dev/device

Below is a sample output of this command, which displays the resulting file system geometry and features:

⁠

Example 6.1. 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.

For striped block devices (for example, RAID5 arrays), the stripe geometry can be specified at the time of file system creation. Using proper stripe geometry greatly enhances the performance of an ext4 file system.

When creating file systems on LVM or MD volumes,  mkfs.ext4 chooses an optimal geometry. This may also be true on some hardware RAIDs which export geometry information to the operating system.

To specify stripe geometry, use the  -E option of  mkfs.ext4 (that is, extended file system options) with the following sub-options:

stride=value

Specifies the RAID chunk size.

stripe-width=value

Specifies the number of data disks in a RAID device, or the number of stripe units in the stripe.

For both sub-options,  value must 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

For more information about creating file systems, refer to  man mkfs.ext4.

Important

It is possible to use  tune2fs to 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.

⁠6.2. Mounting an Ext4 File System

An ext4 file system can be mounted with no extra options. For example:

# mount /dev/device /mount/point

The ext4 file system also supports several mount options to influence behavior. For example, the  acl parameter enables access control lists, while the  user_xattr parameter enables user extended attributes. To enable both options, use their respective parameters with  -o, as in:

# mount -o acl,user_xattr /dev/device /mount/point

The  tune2fs utility also allows administrators to set default mount options in the file system superblock. For more information on this, refer to  man tune2fs.

⁠Write Barriers

By default, ext4 uses write barriers to ensure file system integrity even when power is lost to a device with write caches enabled. For devices without write caches, or with battery-backed write caches, disable barriers using the nobarrier option, as in:

# mount -o nobarrier /dev/device /mount/point

For more information about write barriers, refer to  Chapter 22, Write Barriers.

⁠6.3. Resizing an Ext4 File System

Before growing an ext4 file system, ensure that the underlying block device is of an appropriate size to hold the file system later. Use the appropriate resizing methods for the affected block device.

An ext4 file system may be grown while mounted using the  resize2fs command:

# resize2fs /mount/device node

The  resize2fs command can also decrease the size of an  unmounted ext4 file system:

# resize2fs /dev/device size

When resizing an ext4 file system, the  resize2fs utility reads the size in units of file system block size, unless a suffix indicating a specific unit is used. The following suffixes indicate specific units:

• s — 512 byte sectors
• K — kilobytes
• M — megabytes
• G — gigabytes

Note

The size parameter is optional (and often redundant) when expanding. The  resize2fs automatically expands to fill all available space of the container, usually a logical volume or partition.

For more information about resizing an ext4 file system, refer to  man resize2fs.

⁠6.4. Backup ext2/3/4 File Systems

⁠

Procedure 6.1. Backup ext2/3/4 File Systems Example

1. All data must be backed up before attempting any kind of restore operation. Data backups should be made on a regular basis. In addition to data, there is configuration information that should be saved, including  /etc/fstab and the output of  fdisk -l. Running an sosreport/sysreport will capture this information and is strongly recommended.

   # cat /etc/fstab
   LABEL=/            /               ext3    defaults        1 1
   LABEL=/boot1       /boot           ext3    defaults        1 2
   LABEL=/data        /data           ext3    defaults        0 0
   tmpfs              /dev/shm        tmpfs   defaults        0 0
   devpts             /dev/pts        devpts  gid=5,mode=620  0 0
   sysfs              /sys            sysfs   defaults        0 0
   proc               /proc           proc    defaults        0 0
   LABEL=SWAP-sda5    swap            swap    defaults        0 0
   /dev/sda6          /backup-files   ext3    defaults        0 0
   
   # fdisk -l
      Device Boot    Start      End    Blocks      Id  System
   /dev/sda1 *           1       13    104391      83  Linux
   /dev/sda2            14      1925   15358140    83  Linux
   /dev/sda3          1926      3200   10241437+   83  Linux
   /dev/sda4          3201      4864   13366080    5   Extended
   /dev/sda5          3201      3391   1534176     82  Linux swap / Solaris
   /dev/sda6          3392      4864   11831841    83  Linux
   

   In this example, we will use the  /dev/sda6 partition to save backup files, and we assume that  /dev/sda6 is mounted on  /backup-files.
2. If the partition being backed up is an operating system partition, bootup your system into Single User Mode. This step is not necessary for normal data partitions.
3. Use  dump to backup the contents of the partitions:

   Note

   • If the system has been running for a long time, it is advisable to run  e2fsck on the partitions before backup.
   • dump should not be used on heavily loaded and mounted filesystem as it could backup corrupted version of files. This problem has been mentioned on  dump.sourceforge.net.

     Important

     When backing up operating system partitions, the partition must be unmounted.

     While it is possible to back up an ordinary data partition while it is mounted, it is adviseable to unmount it where possible. The results of attempting to back up a mounted data partition can be unpredicteable.

   # dump -0uf /backup-files/sda1.dump /dev/sda1
   # dump -0uf /backup-files/sda2.dump /dev/sda2
   # dump -0uf /backup-files/sda3.dump /dev/sda3
   

   If you want to do a remote backup, you can use both ssh or configure a non-password login.

   Note

   If using standard redirection, the '-f' option must be passed separately.

   # dump -0u -f - /dev/sda1 | ssh root@remoteserver.example.com dd of=/tmp/sda1.dump
   

⁠6.5. Restore an ext2/3/4 File System

⁠

Procedure 6.2. Restore an ext2/3/4 File System Example

1. If you are restoring an operating system partition, bootup your system into Rescue Mode. This step is not required for ordinary data partitions.
2. Rebuild sda1/sda2/sda3/sda4/sda5 by using the  fdisk command.

   Note

   If necessary, create the partitions to contain the restored file systems. The new partitions must be large enough to contain the restored data. It is important to get the start and end numbers right; these are the starting and ending sector numbers of the partitions.
3. Format the destination partitions by using the  mkfs command, as shown below.

   Important

   DO NOT format  /dev/sda6 in the above example because it saves backup files.

   # mkfs.ext3 /dev/sda1
   # mkfs.ext3 /dev/sda2
   # mkfs.ext3 /dev/sda3
   

4. If creating new partitions, re-label all the partitions so they match the  fstab file. This step is not required if the partitions are not being recreated.

   # e2label /dev/sda1 /boot1
   # e2label /dev/sda2 /
   # e2label /dev/sda3 /data
   # mkswap -L SWAP-sda5 /dev/sda5
   

5. Prepare the working directories.

   # mkdir /mnt/sda1
   # mount -t ext3 /dev/sda1 /mnt/sda1
   # mkdir /mnt/sda2
   # mount -t ext3 /dev/sda2 /mnt/sda2
   # mkdir /mnt/sda3
   # mount -t ext3 /dev/sda3 /mnt/sda3
   # mkdir /backup-files
   # mount -t ext3 /dev/sda6 /backup-files
   

6. Restore the data.

   # cd /mnt/sda1
   # restore -rf /backup-files/sda1.dump
   # cd /mnt/sda2
   # restore -rf /backup-files/sda2.dump
   # cd /mnt/sda3
   # restore -rf /backup-files/sda3.dump
   

   If you want to restore from a remote host or restore from a backup file on a remote host you can use either ssh or rsh. You will need to configure a password-less login for the following examples:
   Login into 10.0.0.87, and restore sda1 from local sda1.dump file:

   # ssh 10.0.0.87 "cd /mnt/sda1 && cat /backup-files/sda1.dump | restore -rf -"
   

   Login into 10.0.0.87, and restore sda1 from a remote 10.66.0.124 sda1.dump file:

   # ssh 10.0.0.87 "cd /mnt/sda1 && RSH=/usr/bin/ssh restore -r -f 10.66.0.124:/tmp/sda1.dump"
   

7. Reboot.

⁠6.6. Other Ext4 File System Utilities

Red Hat Enterprise Linux 6 also features other utilities for managing ext4 file systems:

e2fsck

Used to repair an ext4 file system. This tool checks and repairs an ext4 file system more efficiently than ext3, thanks to updates in the ext4 disk structure.

e2label

Changes the label on an ext4 file system. This tool also works on ext2 and ext3 file systems.

quota

Controls and reports on disk space (blocks) and file (inode) usage by users and groups on an ext4 file system. For more information on using  quota, refer to  man quota and  Section 16.1, “Configuring Disk Quotas”.

As demonstrated in  Section 6.2, “Mounting an Ext4 File System”, the  tune2fs utility can also adjust configurable file system parameters for ext2, ext3, and ext4 file systems. In addition, the following tools are also useful in debugging and analyzing ext4 file systems:

debugfs

Debugs ext2, ext3, or ext4 file systems.

e2image

Saves critical ext2, ext3, or ext4 file system metadata to a file.

For more information about these utilities, refer to their respective  man pages.