Redhat Ext4 File System Guide

⁠Chapter 6. The Ext4 File System

6.1.
Creating an Ext4 File System
6.2.
Mounting an Ext4 File System
6.3.
Resizing an Ext4 File System
6.4.
Backup ext2/3/4 File Systems
6.5.
Restore an ext2/3/4 File System
6.6.
Other Ext4 File System Utilities

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, seeChapter 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:

# [code]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:

# [code]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:

# [code]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:

# [code]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:

# [code]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:

# [code]resize2fs /mount/device node

The

resize2fs

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

# [code]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

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

.

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.

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

If you are restoring an operating system partition, bootup your system into Rescue Mode. This step is not required for ordinary data partitions.

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.

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

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

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

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"

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.