Chapter 3. The XFS File System
- Main Features
- XFS supports metadata journaling, which facilitates quicker crash recovery. The XFS file system can also be defragmented and enlarged while mounted and active. In addition, Red Hat Enterprise Linux 7 supports backup and restore utilities specific to XFS.
- Allocation Features
- XFS features the following allocation schemes:
Delayed allocation and other performance optimizations affect XFS the same way that they do ext4. Namely, a program's writes to an XFS file system are not guaranteed to be on-disk unless the program issues an
- Extent-based allocation
- Stripe-aware allocation policies
- Delayed allocation
- Space pre-allocation
fsync()call afterwards.For more information on the implications of delayed allocation on a file system (ext4 and XFS), refer to Allocation Features in Chapter 5, The Ext4 File System.
NoteCreating or expanding files occasionally fails with an unexpected ENOSPC write failure even though the disk space appears to be sufficient. This is due to XFS's performance-oriented design. In practice, it does not become a problem since it only occurs if remaining space is only a few blocks.
- Other XFS Features
- The XFS file system also supports the following:
- Extended attributes (
- This allows the system to associate several additional name/value pairs per file. It is enabled by default.
- Quota journaling
- This avoids the need for lengthy quota consistency checks after a crash.
- Project/directory quotas
- This allows quota restrictions over a directory tree.
- Subsecond timestamps
- This allows timestamps to go to the subsecond.
- Extended attributes (
Relatimeis on by default for XFS. It has almost no overhead compared to
noatimewhile still maintaining sane
3.1. Creating an XFS File System
mkfs.xfs /dev/devicecommand. In general, the default options are optimal for common use.
mkfs.xfson a block device containing an existing file system, use the
-foption to force an overwrite of that file system.
mkfs.xfs command output
meta-data=/dev/device isize=256 agcount=4, agsize=3277258 blks = sectsz=512 attr=2 data = bsize=4096 blocks=13109032, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=6400, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0
xfs_growfscommand (refer to Section 3.4, “Increasing the Size of an XFS File System”).
mkfs.xfschooses an optimal geometry. This may also be true on some hardware RAIDs that export geometry information to the operating system.
mkfs(for ext3, ext4, and xfs) will automatically use this geometry. If stripe geometry is not detected by mkfs and even though the storage does, in fact, have stripe geometry, it is possible to manually specify it at mkfs time using the following options:
- Specifies a stripe unit or RAID chunk size. The
valuemust be specified in bytes, with an optional
- Specifies the number of data disks in a RAID device, or the number of stripe units in the stripe.
# mkfs.xfs -d su=64k,sw=4 /dev/device
man mkfs.xfsand the Red Hat Enterprise Linux Performance Tuning Guide, chapter Basic Tuning for XFS.