2

We have an inode number that we're trying to associate to an actual file name. The filesystem is XFS. Looking there are examples that purport to be able to accomplish this with xfs_db and/or xfs_ncheck but thus far we've been unsuccessful in doing this.

Example

We're triaging an issue where we'd like to find the filenames associated to the inode numbers which show up in a procs fdinfo file under /proc.

$ grep inotify /proc/9652/fdinfo/23 | head
inotify wd:58eb9 ino:cfd30c7 sdev:20 mask:3c0 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:c730fd0c00000000
inotify wd:58eb8 ino:cfd1f09 sdev:1e mask:3c0 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:091ffd0c00000000
inotify wd:58eb7 ino:cfd1ee9 sdev:1a mask:3c0 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:e91efd0c00000000
inotify wd:58eb6 ino:cfd1ec8 sdev:1c mask:3c0 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:c81efd0c00000000
inotify wd:58eb5 ino:cfd1eb9 sdev:19 mask:3c0 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:b91efd0c00000000
inotify wd:58eab ino:cfd24cf sdev:20 mask:3c0 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:cf24fd0c00000000
inotify wd:58eaa ino:cfdbc51 sdev:1e mask:3c0 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:51bcfd0c00000000
inotify wd:58ea9 ino:cfdbc31 sdev:1a mask:3c0 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:31bcfd0c00000000
inotify wd:58ea8 ino:cfdbc0f sdev:1c mask:3c0 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:0fbcfd0c00000000
inotify wd:58ea7 ino:cfdb000 sdev:19 mask:3c0 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:00b0fd0c00000000

These inodes are in HEX so we need to convert them to DEC:

$ echo $((16#cfd30c7))
217919687

Using xfs_ncheck:

$ xfs_ncheck -i $(echo $((16#cfd30c7))) /dev/mapper/vg0-dockerlv
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_ncheck.  If you are unable to mount the filesystem, then use
the xfs_repair -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.
must run blockget -n first

Questions

  • How can we do this with XFS?
  • I've done similar things using debugfs and ext3/4 filesystems but this doesn't seem as easy with XFS?

References

2

In theory the command should work, but in practice, xfs_ncheck is a shell script around xfs_db and xfs_db very much prefers cleanly unmounted filesystems:

# xfs_db /dev/SSD/root 
xfs_db: /dev/SSD/root contains a mounted filesystem
fatal error -- couldn't initialize XFS library

So by default, for mounted filesystems it does not even run at all, additional options are required to ignore mounted state (implied by xfs_ncheck) but even then, on a mounted or otherwise unclean filesystem, xfs_db-related commands often don't work as expected, and then you get a somewhat unclear message about logs that need to be replayed and the like.

So you'd have to umount, or re-mount read-only, or use a copy-on-write snapshot to produce a clean filesystem image to run those commands successfully.

But if it's just the regular inode number, for a mounted filesystem, you can just as well use

find /path/to/mountpoint -xdev -inum X

But this won't find already deleted files and might also miss files hidden under other mountpoints (in that case consider mount --bind instead of -xdev).

Also note that inum-filename correlation can be somewhat arbitrary in case of hardlinks and the like.

| improve this answer | |
  • ty for the quick reply and explanation. We've been using the find but wanted something quicker. Guess that's as good as we can get with XFS. – slm Jan 15 at 16:09
  • 1
    @slm according to manpage, xfs_db ncheck Print name-inode pairs. A blockget -n command must be run first to gather the information., xfs_db blockget -n This option uses a lot of memory, … so it's a two-step process and what I assume happens here is it walks the entire filesystem, puts all inode-filenames in memory (regardless whether you want them or not), ...which does not sound performant, but I haven't benchmarked it. Could be better or worse than find depending on how much difference all those filesystem syscalls make...? – frostschutz Jan 15 at 16:40
  • 1
    @slm if there's something quicker (without maintaining a persistent cache) then I can't think of it at the moment – frostschutz Jan 15 at 16:40
  • This is all good stuff, thank you for the help/guidance! – slm Jan 15 at 16:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.