XFS
XFS is a high-performance, 64-bit journaling filesystem. It was originally created by Silicon Graphics (SGI) in 1993 for their IRIX operating system and was later ported to the Linux kernel in 2001.
If ext4 is the "reliable sedan" of Linux filesystems, XFS is the "heavy-duty semi-truck." It is designed for massive scale, high throughput, and parallel operations.
Key Technical Features
XFS has several architectural "superpowers" that make it stand out:
- Allocation Groups (AGs): XFS divides the disk into multiple equal-sized chunks called Allocation Groups. Each AG manages its own free space and inodes.
- Why this matters: It allows the kernel to perform I/O operations in parallel. On a multi-core CPU, different threads can write to different AGs simultaneously without locking each other out.
- Journaling: It keeps a log (journal) of metadata changes. If the power cuts out, the filesystem doesn't need a full
fsck(disk check); it just replays the journal to recover in seconds. - B+ Trees: XFS uses B+ trees to track almost everything (extents, free space, and inodes). This makes searching for data extremely fast, even on disks with millions of files.
- Massive Limits: It supports files up to 8 exabytes and filesystems up to 16 exabytes. While we don't have hard drives that big yet, XFS is "future-proofed."
- Delayed Allocation: XFS waits until the last possible second to decide where to put data on the disk. This allows it to find the best contiguous space, which reduces fragmentation.
Where is it used?
Enterprise Linux Distributions
XFS is the default filesystem for:
- Red Hat Enterprise Linux (RHEL) (Since version 7.0)
- CentOS / AlmaLinux / Rocky Linux
- Oracle Linux
High-Performance Storage & Big Data
Because of its parallel nature, XFS is the top choice for:
- Large Databases: (PostgreSQL, MySQL, MongoDB) where multiple threads are writing to the disk at once.
- Video Production: Handling massive 4K/8K video files requires high sequential throughput, which is an XFS specialty.
- HPC (High-Performance Computing): Used in supercomputer clusters for massive data processing.
The Cloud and Containers
XFS is a very popular backing store for container runtimes (containerd, Docker). Large cloud providers often use XFS for the root disks of their virtual machines because it is more robust than ext4 when dealing with very large volumes.
XFS vs. ext4: The Trade-offs
| Feature | ext4 | XFS |
|---|---|---|
| Max Partition Size | 1 Exabyte | 16 Exabytes |
| Shrinking | Yes (Can be reduced in size) | No (Cannot be shrunk) |
| Parallel I/O | Limited | Excellent (via AGs) |
| Performance (Small Files) | Often faster | Slightly slower |
| Performance (Large Files) | Good | Excellent |
The "Expert" Warning: You can't shrink it
The biggest "gotcha" with XFS is that it cannot be shrunk.
- If you have a 10TB XFS partition and you decide you want to make it 5TB to free up space, you are out of luck.
- You have to back up the data, delete the partition, recreate it at 5TB, and restore the data.
Note: You can grow XFS while it is mounted and live, but never shrink it.
What is ftype=1
The ftype setting is a specific feature of the XFS filesystem that determines whether directory entries should store information about the type of file they point to (e.g., is this a directory, a symlink, or a regular file?).
In technical terms, ftype=1 enables support for the d_type (directory entry type) field.
This sounds like a minor detail, but for OverlayFS (and therefore containerd and Docker), it is a "make or break" requirement.
The Analogy: The Library Index
Imagine a library's card catalog (the Directory).
ftype=0(Legacy): Each card only has the name of the item. To find out if that item is a Book, a Map, or a DVD, you have to actually walk to the shelf and look at the item itself (this is an "Inode Lookup").ftype=1(Modern): Each card has the name and a small icon telling you immediately if it’s a book, map, or DVD. You don't have to walk to the shelf.
Why OverlayFS Requires ftype=1
OverlayFS works by "merging" multiple directories. To do this efficiently, it needs to know the type of a file instantly as it scans a directory.
The most critical reason is Whiteouts.
In a container, when you "delete" a file that exists in a lower (read-only) layer, OverlayFS doesn't actually delete the file. Instead, it creates a Character Device with a specific major/minor number in the upperdir. This is called a "whiteout."
- If
ftype=0: OverlayFS has to perform a fullstat(inode lookup) on every single file in the directory to see if any of them are these special "whiteout" devices. This makes opening a directory incredibly slow. - If
ftype=1: OverlayFS can see the file type directly in the directory entry. It can skip regular files and only "react" to the special character devices.
If you try to use OverlayFS on an XFS partition with ftype=0, the Linux kernel will often refuse to mount it, or your container engine will throw an error.
Comparison Table
| Feature | ftype=0 |
ftype=1 |
|---|---|---|
| Meaning | Directory entry type info is Disabled. | Directory entry type info is Enabled. |
| Speed | Slower for directory traversal (ls, find). |
Faster for traversal and merging. |
| Compatibility | Not compatible with OverlayFS. | Required for OverlayFS / Containers. |
| Default | Standard in older Linux (RHEL 6). | Default in modern Linux (RHEL 7.3+, Ubuntu, etc.). |
How to Check Your Filesystem
If you are on an XFS system, you can check this using the xfs_info tool:
# Check the root filesystem (or whichever path holds your containers)
xfs_info / | grep ftype
- If you see
ftype=1, you are good to go. - If you see
ftype=0, you cannot runcontainerdwithoverlayfson this partition.
Can you change it?
No. ftype is a structural feature of the filesystem metadata. It is set at the moment the partition is formatted.
If you have an ftype=0 partition and you need ftype=1, you must:
- Back up your data.
- Reformat the partition:
mkfs.xfs -n ftype=1 /dev/sdX. - Restore your data.