Migrating from ext4 to XFS File System
Starting with Red Hat Enterprise Linux 7.0, XFS is the default file system instead of ext4. This section highlights the differences when using or administering an XFS file system.
The ext4 file system is still fully supported in Red Hat Enterprise Linux 7 and can be selected at installation. While it is possible to migrate from ext4 to XFS, it is not required.
Commands used with ext3 and ext4 compared to XFS
The following table compares common commands used with ext3 and ext4 to their XFS-specific counterparts.
Common Commands for ext3 and ext4 Compared to XFS
|Create a file system||
|File system check||
|Resizing a file system||
|Save an image of a file system||
|Label or tune a file system||
|Backup a file system||
The following table lists generic tools that function on XFS file systems as well, but the XFS versions have more specific functionality and as such are recommended.
Generic tools for ext4 and XFS
More information on many the listed XFS commands is included in Chapter 3, The XFS File System. You can also consult the manual pages of the listed XFS administration tools for more information.
Behavioral and Administrative Differences Between Ext3/4 and XFS
- File system repair
e2fsckin userspace at boot time to recover the journal as needed. XFS, by comparison, performs journal recovery in kernelspace at mount time. An
fsck.xfsshell script is provided but does not perform any useful action as it is only there to satisfy initscript requirements.When an XFS file system repair or check is requested, use the
xfs_repaircommand. Use the
-noption for a read-only check.The
xfs_repaircommand will not operate on a file system with a dirty log. To repair such a file system
unmountmust first be performed to replay the log. If the log is corrupt and cannot be replayed, the
-Loption can be used to zero out in the log.
- Metadata error behavior
The ext3/4 file system has configurable behavior when metadata errors are encountered, with the default being to simply continue. When XFS encounters a metadata error that is not recoverable it will shut down the file system and return a
EFSCORRUPTEDerror. The system logs will contain details of the error enountered and will recommend running
XFS quotas are not a remountable option. The
-o quotaoption must be specified on the initial mount for quotas to be in effect.While the standard tools in the quota package can perform basic quota administrative tasks (tools such as setquota and repquota), the xfs_quota tool can be used for XFS-specific features, such as Project Quota administration.The
quotacheckcommand has no effect on an XFS file system. The first time quota accounting is turned on XFS does an automatic
quotacheckinternally. Because XFS quota metadata is a first-class, journaled metadata object, the quota system will always be consistent until quotas are manually turned off.
- File system resize
The XFS file system has no utility to shrink a file system. XFS file systems can be grown online via the
- Inode numbers
For file systems larger than 1 TB with 256-byte inodes, or larger than 2 TB with 512-byte inodes, XFS inode numbers might exceed 2^32. Such large inode numbers cause 32-bit stat calls to fail with the EOVERFLOW return value. The described problem might occur when using the default Red Hat Enterprise Linux 7 configuration: non-striped with four allocation groups. A custom configuration, for example file system extension or changing XFS file system parameters, might lead to a different behavior.Applications usually handle such larger inode numbers correctly. If needed, mount the XFS file system with the
-o inode32parameter to enforce inode numbers below 2^32. Note that using
inode32does not affect inodes that are already allocated with 64-bit numbers.
ImportantDo not use the
inode32option unless it is required by a specific environment. The
inode32option changes allocation behavior. As a consequence, the ENOSPC error might occur if no space is available to allocate inodes in the lower disk blocks.
- Speculative preallocation
XFS uses speculative preallocation to allocate blocks past EOF as files are written. This avoids file fragmentation due to concurrent streaming write workloads on NFS servers. By default, this preallocation increases with the size of the file and will be apparent in “du” output. If a file with speculative preallocation is not dirtied for five minutes the preallocation will be discarded. If the inode is cycled out of cache before that time, then the preallocation will be discarded when the inode is reclaimed.If premature ENOSPC problems are seen due to speculative preallocation, a fixed preallocation amount may be specified with the
-o allocsize=amountmount option.
- Fragmentation-related tools
Fragmentation is rarely a significant issue on XFS file systems due to heuristics and behaviors, such as delayed allocation and speculative preallocation. However, tools exist for measuring file system fragmentation as well as defragmenting file systems. Their use is not encouraged.The
xfs_db fragcommand attempts to distill all file system allocations into a single fragmentation number, expressed as a percentage. The output of the comand requires significant expertise to understand its meaning. For example, a fragmentation factor of 75% means only an average of 4 extents per file. For this reason the output of xfs_db’s frag is not considered useful and more careful analysis of any fragmentation problems is recommended.
xfs_fsrcommand may be used to defragment individual files, or all files on a file system. The later is especially not recommended as it may destroy locality of files and may fragment freespace.