Inspect an XFS Log Safely with xfs_logprint

Something has gone wrong with an XFS filesystem, and xfs_logprint is how you read what the log recorded before the crash. You will see the ordinary record view, the recovery-oriented transactional view, and a header-only check. The command reads the filesystem; it does not repair it or mount it.

Allow about fifteen minutes for a first inspection. You need the xfsprogs package, a readable XFS device or image, and enough disk space if you choose to copy the log. The examples use xfs_logprint 6.6.0 from xfsprogs 6.6.0-1ubuntu2.1. Output details can differ between filesystem images and package releases.

1. Confirm the installed command

Check the binary and its version first. This is read-only and normally unprivileged:

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

If the path or version differs, keep the installed manual page beside you. Do not copy an option from a different release without checking it with man xfs_logprint.

2. Choose a safe input

The final argument is the partition or logical volume containing the XFS filesystem. Replace /dev/DEVICE with the correct path from your own host:

$ lsblk -f
$ sudo xfs_logprint /dev/DEVICE

The first command is an ordinary inventory check. The second reads the target and may need elevated privileges. Verify the device carefully before running it: xfs_logprint does not alter the filesystem contents, but reading the wrong device still produces misleading evidence.

For a regular image file, add -f. That option changes how the argument is interpreted; it does not convert an arbitrary file into an XFS image:

$ file /path/to/xfs-image
$ xfs_logprint -f /path/to/xfs-image

Do not point the command at a mounted filesystem's ordinary directory. It expects the filesystem device or a compatible image file.

3. Read the ordinary log view

With no mode option, the command starts at the beginning of the log and displays one log record at a time. It reports when it reaches the physical and logical ends. Transactions spanning multiple records might not be decoded completely:

$ sudo xfs_logprint /dev/DEVICE > xfs-log-records.txt
$ wc -l xfs-log-records.txt
$ less xfs-log-records.txt

Redirecting to a new file keeps a large diagnostic dump out of your terminal. Shell redirection truncates an existing destination before the command starts, so use a new filename or make a backup before replacing an existing report. If the command fails, inspect the report for a partial result and rerun with a distinct name.

4. Switch to the transactional view

Use -t when the question is about filesystem recovery. This view prints complete transactions between the log tail and head where possible, even when those transactions cross log records:

$ sudo xfs_logprint -t /dev/DEVICE > xfs-log-transactions.txt
$ sed -n '1,80p' xfs-log-transactions.txt

The transactional view is the useful starting point for operation debugging. Its specialised extractors are also restricted to this view:

$ sudo xfs_logprint -t -b -i -q /dev/DEVICE > xfs-log-details.txt

-b extracts buffer information, -i extracts inode information, and -q extracts quota information. Add only the category you need when the output will be reviewed by someone else. None of these options repair buffers, inodes or quotas: they only print what is already there.

5. Start with headers when decoding is distracting

Use -n to interpret log header information without trying to interpret log data:

$ sudo xfs_logprint -n /dev/DEVICE
xfs_logprint:
    data device: ...
    log device: ...

The exact device identifiers, block counts and warnings depend on the target. A header-only run is a useful checkpoint when a full dump is noisy or a damaged log produces decoding errors. It is an inspection result, not a clean bill of health.

For a regular image, combine the options:

$ xfs_logprint -f -n /path/to/xfs-image

If the image has an external log, supply that device with -l /path/to/logdev. Use this only when the filesystem actually uses an external log; guessing a log device can make a valid investigation fail.

6. Preserve or copy the log for hand-off

To copy the log without printing it, use -C and a destination you control:

$ sudo xfs_logprint -C /tmp/xfs-log-copy.bin /dev/DEVICE
$ file /tmp/xfs-log-copy.bin
$ ls -lh /tmp/xfs-log-copy.bin

-C copies the log and does not print it. Run a separate inspection against the copy when you need text output:

$ xfs_logprint -f -n /tmp/xfs-log-copy.bin

This last command is only appropriate when the copied file is a filesystem image in the form expected by -f. A log-only copy is for hand-off or later processing, not automatically a complete filesystem image.

7. Handle errors without escalating the damage

By default, xfs_logprint tries to continue and unwind from bad log data, though the manual admits it can sometimes die badly instead. Use -e when you need it to exit as soon as it finds an error and to avoid a core dump:

$ sudo xfs_logprint -e /dev/DEVICE > xfs-log-strict.txt
$ printf 'exit status: %s\n' "$?"

Use -c when you specifically want it to attempt to continue after an error. Do not treat either choice as recovery: neither option writes repairs, and neither replaces a backup or a filesystem recovery plan.

The diagnostic options -D, -d, -o, -s and -v change how data is displayed or where printing starts. Add them only to answer a defined question. In particular, -s overrides the normal starting position, so it can hide the context you expected if you use it casually.