Inspect an XFS Log Safely with xfs_logprint

You will inspect the log belonging to an XFS filesystem, either by reading its device directly or by analysing a regular image file. 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.

Privilege boundary: reading a block device normally requires elevated access, so use sudo only when your account cannot read it. Reading a copy in a directory you own does not need sudo.

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. 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.

Some error blocks at the start are possible because the last log record can overlap the oldest one. That message is a property of the log layout, not by itself proof that the whole filesystem is damaged.

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. The options do not repair buffers, inodes or quotas.

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

This changes state by creating or overwriting the destination file. Check the path before pressing Enter. If it is an existing report, choose a new filename or preserve it first. The copied log is sensitive filesystem diagnostic data: restrict its permissions and transfer it only through an approved channel.

-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. 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.