Read XFS Geometry Safely with xfs_info

xfs_info prints the geometry of an existing XFS filesystem, with nothing repaired, mounted, unmounted or resized along the way. It reports the fields that matter for capacity and layout checks, and nothing else: this command only reports metadata.

Allow about ten minutes. You need the xfsprogs package and either a mounted XFS path, a block device, or an XFS file image. The examples use xfsprogs 6.6.0, installed on this machine as package version 6.6.0-1ubuntu2.1. Output from another release can contain additional fields.

1. Check the installed command

Start with version and path checks. These are ordinary, read-only commands and normally need no elevated privileges:

$ command -v xfs_info
/usr/sbin/xfs_info
$ xfs_info -V
xfs_info version 6.6.0
$ dpkg-query -W -f='${Package} ${Version}\n' xfsprogs
xfsprogs 6.6.0-1ubuntu2.1

Keep the version beside any diagnostic record. XFS tools evolve, and newer output can include fields that an older guide does not mention.

2. Choose the least surprising input

The documented inputs are a mount-point directory, a block device, or a raw XFS file-image. Pass one input, not a filesystem label or an arbitrary directory. A mounted filesystem example looks like this:

$ xfs_info /srv/data

Replace /srv/data with a directory that is actually an XFS mount. To identify it before running the command, use:

$ findmnt -t xfs
TARGET   SOURCE     FSTYPE OPTIONS
/srv/data /dev/XXX  xfs    rw,relatime

The target and source are host-specific. The command only reads geometry, but access to a device node or mount path can still be restricted. Use sudo only if the read itself fails with a permissions error:

$ sudo xfs_info /dev/XXX

Do not guess a device name. Confirm it with findmnt, lsblk or your storage documentation first.

3. Inspect an existing image without mounting it

A file-image is useful when you have an image to examine and do not want to mount it. This example is read-only with respect to the image:

$ xfs_info /path/to/existing-filesystem.img
meta-data=/path/to/existing-filesystem.img isize=512    agcount=4, agsize=32768 blks
         =                       sectsz=512   attr=2, projid32bit=1
data     =                       bsize=4096   blocks=131072, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=16384, version=2
realtime =none                   extsz=4096   blocks=0, rtextents=0

The exact lines depend on how the filesystem was created. The useful checkpoint is an exit status of zero followed by geometry sections such as meta-data, data, naming, log and realtime. Capture the status explicitly when using the result in a script:

$ xfs_info /path/to/existing-filesystem.img > xfs-geometry.txt
$ status=$?
$ printf 'xfs_info status: %s\n' "$status"
xfs_info status: 0

Redirecting the report to a new file does not alter the filesystem. Shell redirection with > does truncate an existing report, so choose a new name or use set -o noclobber if preserving old diagnostics matters.

4. Read the data section first

The data line gives the filesystem block size in bsize and the count in blocks. In the example, bsize=4096 means each XFS data block is 4096 bytes, while blocks=131072 is the filesystem's data-block count. Do not multiply fields blindly when estimating usable capacity: allocation groups, metadata, reserved space and filesystem features also matter.

The sunit and swidth values are expressed in filesystem blocks. In a report with bsize=4096, sunit=32 represents 32 x 4096 bytes, or 128 KiB. swidth=128 represents 512 KiB: that is four stripe units. Values of zero, as in the sample image, mean no stripe geometry is reported there. Do not invent a RAID layout from zeroes or infer one from a device name.

5. Interpret the other sections without changing state

• meta-data includes inode size, allocation-group count and feature indicators such as CRC, reflink or reverse mapping.
• naming describes directory format and filename-related features.
• log identifies the journal location and geometry.
• realtime reports a realtime device when one exists, or none when it does not.

These are descriptions of the existing filesystem. xfs_info does not validate every file, replay the log, repair metadata or change any of these settings. If you need repair, stop and select the appropriate XFS repair workflow for an unmounted filesystem. Do not run a repair command against a live filesystem merely because an xfs_info report looks unfamiliar.

6. Diagnose the common failures

A message such as not a valid XFS filesystem usually means the argument is the wrong device or image, the image is damaged, or the filesystem type is different. Check the input without writing to it:

$ findmnt -no SOURCE,FSTYPE,TARGET /srv/data
/dev/XXX xfs /srv/data
$ file /path/to/existing-filesystem.img
$ xfs_info /path/to/existing-filesystem.img
$ printf 'status: %s\n' "$?"

A non-zero status is a failure to obtain a trustworthy report. It is not a reason to add a force option or run a repair tool immediately.

The installed 6.6.0 binary also prints a usage form that includes options such as -i, -f, -F, -r, -x and command arguments. The local manpage documents -t for an alternate mount table and -V for the version.

On this installation, -t is rejected by the binary's usage parser, including when the input is a file-image. Treat the installed command and its version as authoritative for scripts, and test any option on the target host before relying on it. The ordinary one-input form above avoids this mismatch.