How to Inspect and Modify XFS Filesystem Parameters in Linux Using xfs_admin and xfs_info

XFS is a high-performance, 64-bit journaling filesystem widely deployed across enterprise Linux distributions, storage arrays, and database servers. Renowned for its scalability and multi-threaded parallel I/O capabilities, XFS structures data across independent allocation groups (AGs). While filesystems like ext4 rely on offline utilities for general maintenance, XFS maintains strict distinctions between active online queries and offline parameter adjustments. To query internal geometry, inspect allocation groups, modify filesystem volume labels, and regenerate unique identifiers (UUIDs), Linux administrators utilise xfs_info and xfs_admin.

Understanding XFS Allocation Groups and Metadata Architecture

An XFS filesystem is divided into multiple autonomous allocation groups (AGs). Each allocation group functions essentially as an independent storage entity, managing its own free space b-trees, inode allocations, and block tracking headers. This architectural design allows multiple CPU cores and processes to execute concurrent allocation requests simultaneously without file lock contention.

When tuning storage arrays or investigating volume replication, administrators use two specialized tools:

• xfs_info: An online utility that queries an actively mounted XFS filesystem to display block sizes, allocation group counts, sector geometry, and journaling parameters.
• xfs_admin: An offline maintenance utility executed against an unmounted block device to modify filesystem labels, update UUIDs, and alter feature flags.

Querying Mounted Filesystem Geometry with xfs_info

To inspect the low-level geometry of an active XFS filesystem, run xfs_info pointing to its mount point or device node:

sudo xfs_info /mnt/data

The command outputs a structured block detailing filesystem dimensions and capabilities:

meta-data=/dev/sdb1              isize=512    agcount=4, agsize=6553600 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=1, inobtcount=1
data     =                       bsize=4096   blocks=26214400, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=12800, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Key architectural fields include:

• agcount & agsize: The number of allocation groups and their block dimensions. Having sufficient AGs (typically 4 or more) ensures multi-threaded write parallelism.
• sectsz & bsize: Sector size (e.g., 4096 bytes for native 4Kn drives) and filesystem block size.
• reflink: Reports whether copy-on-write (CoW) block cloning is enabled (reflink=1), essential for instantaneous file snapshots.
• bigtime: Indicates whether 64-bit timestamp support is active, overcoming the Year 2038 limitation.

Inspecting and Changing Filesystem Labels with xfs_admin

Filesystem labels provide human-readable identifiers that enable persistent mounting in /etc/fstab using LABEL=<name> syntax rather than volatile device nodes like /dev/sdb1.

Before executing xfs_admin, you must unmount the filesystem. Attempting to run xfs_admin on an active mount will return a Device or resource busy error.

sudo umount /mnt/data

Viewing the Current Label

To check the current label assigned to the unmounted partition:

sudo xfs_admin -l /dev/sdb1

The output reports either the existing label string or label = "" if none has been set.

Assigning a New Label

To assign or overwrite the volume label, pass the -L switch followed by a label string (up to a maximum of 12 characters):

sudo xfs_admin -L "BACKUP_DATA" /dev/sdb1

The command updates the superblock and confirms:

writing all SBs
new label = "BACKUP_DATA"

To remove a label entirely, pass an empty string:

sudo xfs_admin -L "" /dev/sdb1

Managing and Regenerating Filesystem UUIDs

Every XFS filesystem contains a Universally Unique Identifier (UUID) stored across all superblock headers. When cloning raw block devices (such as copying a SAN volume or duplicating a virtual machine disk with dd), identical UUIDs will exist on both partitions. The Linux kernel will refuse to mount two devices sharing the same UUID simultaneously, throwing an XFS: Filesystem has duplicate UUID kernel error.

Displaying the Existing UUID

To query the UUID currently embedded in the superblock:

sudo xfs_admin -u /dev/sdb1

Generating a Random New UUID

To generate and write a completely fresh UUID across all allocation group superblocks, pass the -U generate parameter:

sudo xfs_admin -U generate /dev/sdb1

The tool synchronises superblocks and reports:

Clearing log and setting UUID
writing all SBs
new UUID = e5f14a89-3cb2-4012-8703-9f228b3c94d1

Assigning a Specific UUID

If you are restoring an archive and need the partition to match a specific UUID expected by automation scripts or /etc/fstab:

sudo xfs_admin -U e5f14a89-3cb2-4012-8703-9f228b3c94d1 /dev/sdb1

Once updated, you can safely remount the filesystem using sudo mount /dev/sdb1 /mnt/data and verify the new properties using lsblk -f.