我的一些用户在使用软件（在 Scientific Linux 上）时遇到了问题，即在访问使用“inode64”选项挂载的 XFS 文件系统时无法列出目录内容。因此，我已将数据复制到不使用此选项的新创建的 XFS 文件系统。
不幸的是，在切换文件系统的过程中，我无意中用 inode64 选项短暂地挂载了新文件系统。我很快注意到了这个错误并卸载了它，而且我检查过没有文件的修改时间晚于错误发生的时间。
但是，有没有办法创建超过 32 位限制的 inode，而这在文件修改时间中却不明显，有没有办法检查这一点，而不是递归列出整个（6 TB）文件系统并找到最大 inode 值？
答案1
xfs_db 可以在这里帮助您，但需要一点计算。
[root@system]# xfs_info /s2b
元数据=/dev/lxvm/ddn40_s2b isize=512 agcount=150，agsize=52429056 blks
= sectsz=512 属性=1，nfs4acl=0
数据 = bsize=4096 块=7814070272，imaxpct=25
您有 150 个分配组，编号为 0-149，它们的大小为 52429056（4096b）块（200 GB）。
注意：我在以下情况下使用-r（只读）xfs_db。如果使用启用了写入的 xfs_db，您的文件系统可能会变得一团糟。您还可以做一些有用的事情。如果您打算在文件系统上写入，则仅启用 xfs_db 的写入。写入已安装的文件系统可能会与操作系统发生争用。
对于每个分配组的 inode 部分 (agi)，打印出该部分中的 inode 数量：
[root@system]# for i in `seq 0 149` lou $ do lou $ xfs_db -r -c "agi $i" -c "打印计数" /dev/lxvm/ddn40_s2b lou $ 完成 计数 = 1349120 计数 = 1326464 计数 = 1376768 计数 = 1256448 计数 = 1184512 计数 = 1244352 计数 = 1373376 计数 = 1303296 计数 = 0 ...（剩余计数为零）
因此，前七个部分（或 1400 GB）包含 inode，在 inode32 限制内。此过程可让您回答您的问题。而且速度非常快。