XFS Explained
XFS is a high-performance 64-bit journaling file system originally developed by SGI in 1993. It is the default file system in RHEL/CentOS and is increasingly used on Ubuntu for data volumes, database storage, and log aggregation. XFS excels at large file handling and high-throughput sequential writes. Understanding when to choose XFS over ext4 — and what its unique properties mean in practice — helps you make better infrastructure decisions.
Why choose XFS
| Characteristic | XFS behavior | ext4 behavior |
|---|---|---|
| Large files | Excellent (native extent-based) | Good (also uses extents) |
| Parallel writes | Better (allocation groups enable parallel I/O) | Slower under heavy parallel writes |
| Shrinking volumes | Cannot shrink (design limitation) | Can shrink (offline only) |
| Metadata operations | Less efficient with millions of small files | Better for small file workloads |
| Crash recovery | Fast (only metadata journaled) | Fast (ordered journal mode) |
| Max file size | 8 EiB | 16 TiB |
| RHEL/CentOS default | Yes | No |
Choose XFS for: database storage (PostgreSQL, MySQL data directories), large log volumes, streaming media storage, or when building storage stacks compatible with RHEL/CentOS systems.
Creating and mounting XFS
# Install XFS tools
sudo apt install -y xfsprogs
# Create an XFS file system
sudo mkfs.xfs /dev/sdb1
# Create with a label
sudo mkfs.xfs -L data /dev/sdb1
# Create with custom block size (for databases, 4096 matches OS page size)
sudo mkfs.xfs -b size=4096 /dev/sdb1
# Mount XFS
sudo mkdir -p /data
sudo mount -t xfs /dev/sdb1 /data
# Mount with performance options for databases
sudo mount -t xfs -o noatime,nobarrier /dev/sdb1 /data
# nobarrier: disable write barriers (faster, safe only with UPS/battery-backed cache)
# Add to /etc/fstab
UUID=$(sudo blkid -s UUID -o value /dev/sdb1)
echo "UUID=$UUID /data xfs defaults,noatime 0 2" | sudo tee -a /etc/fstab
XFS-specific tools
# Show XFS file system info
sudo xfs_info /data
sudo xfs_info /dev/sdb1
# Check an XFS file system (must be unmounted or mounted read-only)
sudo umount /data
sudo xfs_check /dev/sdb1 # Basic check
sudo xfs_repair -n /dev/sdb1 # Dry-run repair check
# Repair an XFS file system
sudo xfs_repair /dev/sdb1
# Dump XFS file system metadata (for backup/forensics)
sudo xfs_metadump /dev/sdb1 /tmp/sdb1.metadump
# Grow an XFS file system (XFS can grow online, on a mounted volume)
sudo xfs_growfs /data # Grows to fill the underlying device/LV
# Freeze/thaw XFS for consistent snapshots
sudo xfs_freeze -f /data # Freeze (blocks writes for snapshot)
# --- take snapshot here ---
sudo xfs_freeze -u /data # Thaw
⚠️ WARNING: XFS cannot be shrunk once created. If you format a 500 GB partition as XFS and later want to shrink it to 200 GB, you cannot — you must backup, reformat, and restore. Plan XFS volume sizes carefully, or use LVM so you can add space later. Growing is always possible (
xfs_growfs); shrinking is not.
XFS performance tuning
# For SSD-backed XFS volumes, enable TRIM
# In fstab, add 'discard' option:
UUID=... /data xfs defaults,noatime,discard 0 2
# Or run periodic fstrim instead (less write amplification):
sudo fstrim -v /data
# For databases: align to storage block size and disable access time
UUID=... /data xfs defaults,noatime,nodiratime 0 2
# For Elasticsearch/log storage: improve throughput with larger block size
# Use -d agcount=N when creating to set allocation group count
sudo mkfs.xfs -d agcount=8 /dev/sdb1 # More AGs = better parallelism
XFS limitations
- Cannot shrink: Once formatted, XFS cannot be reduced in size
- Small file performance: Slightly worse than ext4 for workloads with millions of tiny files
- Metadata-only journaling: Data writes are not journaled — there is a small window during which data written but not synced can be lost in a crash (same as ext4 in ordered mode)
- Not default in Ubuntu: ext4 is the Ubuntu default; XFS tooling must be installed separately
Conclusion
XFS is the right choice for Ubuntu data volumes that serve databases, large log files, or media storage — especially if you are also managing RHEL/CentOS systems and want consistent behavior. It cannot be shrunk, so plan volume sizes with room to grow. Always install xfsprogs before creating XFS volumes. Use xfs_growfs for online expansion (no downtime required) and schedule periodic fstrim for SSD-backed volumes.
FAQ
Why should administrators understand XFS Explained?+
Because this topic affects planning decisions, server lifecycle, compatibility, support expectations, or how you reason about Ubuntu systems before making operational changes.
Do I need a lab for this topic?+
A lab is useful for checking commands and seeing the concept on a real Ubuntu machine, but the main value is understanding the decision, tradeoff, or system behavior clearly.
How should I use this knowledge in production?+
Use it to make better choices, document why those choices were made, and avoid rushed changes that ignore support windows, compatibility, stability, or operational risk.
Need help with Ubuntu administration?
Work directly with Muhammad Irfan Aslam for Ubuntu Server, Linux, cloud, Docker, DevOps, CI/CD, or infrastructure troubleshooting support.
Hire Me for Support