xfs_check checks whether an XFS filesystem is consistent.
It is normally run only when there is reason to believe that the
filesystem has a consistency problem.
The filesystem to be checked is specified by the
xfs_special argument, which should be the disk or volume device for the filesystem.
Filesystems stored in files can also be checked, using the <3>-f3><1> flag.
The filesystem should normally be unmounted or read-only
during the execution of
xfs_check . 1>Otherwise, spurious problems are reported.
The options to <2>xfs_check2><1> are:
-f
Specifies that the special device is actually a file (see the
<2>mkfs.xfs2><1> 1><3>-d3><1> 1><2>file2><1> option).
This might happen if an image copy
of a filesystem has been made into an ordinary file.
1>
-l
Specifies the device special file where the filesystem's external
log resides.
Only for those filesystems which use an external log.
See the
<2>mkfs.xfs2><1> 1><3>-l3><1> option, and refer to
xfs(5) 1>for a detailed description of the XFS log.
-s
Specifies that only serious errors should be reported.
Serious errors are those that make it impossible to find major data
structures in the filesystem.
This option can be used to cut down the
amount of output when there is a serious problem, when the output might make it
difficult to see what the real problem is.
-v
Specifies verbose output; it is impossibly long for a
reasonably-sized filesystem.
This option is intended for internal use only.
-i ino
Specifies verbose behavior for a
specific inode.
For instance, it can be used to locate all the blocks
associated with a given inode.
-b bno
Specifies verbose behavior for a specific filesystem block.
For instance, it can be used to determine what a specific block
is used for.
The block number is a "file system block number".
Conversion between disk addresses (i.e. addresses reported by
xfs_bmap ) and file system blocks may be accomplished using
xfs_db 's convert command.
Any output that is produced when
xfs_check is not run in verbose mode indicates
that the filesystem has an inconsistency.
The filesystem can be repaired using either
xfs_repair(8) to fix the filesystem in place,
or by using
xfsdump(8) and
mkfs.xfs(8) to dump the filesystem,
make a new filesystem,
then use
xfsrestore(8) to restore the data onto the new filesystem.
Note that xfsdump may fail on a corrupt filesystem.
However, if the filesystem is mountable, xfsdump can
be used to try and save important data before
repairing the filesystem with xfs_repair.
If the filesystem is not mountable though, xfs_repair is
the only viable option.
1>
DIAGNOSTICS
Under one circumstance,
xfs_check unfortunately might dump core
rather than produce useful output.
If the filesystem is completely corrupt, a core dump might
be produced instead of the message
<2>xxx2><1>1><7> is not a valid filesystem7><1>
1>
If the filesystem is very large (has many files) then
xfs_check might run out of memory.
In this case the message
out of memory
is printed.
The following is a description of the most likely problems and the associated
messages.
Most of the diagnostics produced are only meaningful with an understanding
of the structure of the filesystem.
<7>agf_freeblks 7><1>1><2>n2><1>1><7>, counted 7><1>1><2>m2><1>1><7> in ag 7><1>1><2>a2><1>
The freeblocks count in the allocation group header for allocation group
a doesn't match the number of blocks counted free.
1>
<7>agf_longest 7><1>1><2>n2><1>1><7>, counted 7><1>1><2>m2><1>1><7> in ag 7><1>1><2>a2><1>
The longest free extent in the allocation group header for allocation group
a doesn't match the longest free extent found in the allocation group.
1>
<7>agi_count 7><1>1><2>n2><1>1><7>, counted 7><1>1><2>m2><1>1><7> in ag 7><1>1><2>a2><1>
The allocated inode count in the allocation group header for allocation group
a doesn't match the number of inodes counted in the allocation group.
1>
<7>agi_freecount 7><1>1><2>n2><1>1><7>, counted 7><1>1><2>m2><1>1><7> in ag 7><1>1><2>a2><1>
The free inode count in the allocation group header for allocation group
a doesn't match the number of inodes counted free in the allocation group.
The block number is specified as a pair
(allocation group number, block in the allocation group).
The block is used multiple times (shared), between multiple inodes.
This message usually follows a message of the next type.
1>
<7>block 7><1>1><2>a/b2><1>1><7> expected type unknown got 7><1>1><2>y2><1>
The block is used multiple times (shared).
1>
<7>block 7><1>1><2>a/b2><1>1><7> type unknown not expected7><1>
The block is unaccounted for (not in the freelist and not in use).