我的一些用户在使用“inode64”选项访问XFS文件系统时，无法列出目录内容的软件（在Scientific Linux上）出现问题。 所以我没有这个选项把数据复制到一个新创build的XFS文件系统。
不幸的是，在转换文件系统的过程中，我无意中用inode64选项简单地安装了新的文件系统。 我很快就注意到了这个错误，并卸载了它，并且我已经检查了没有修改时间晚于发生错误的文件。
但是有没有办法创build32位以上的inode，如果没有文件修改的时间，这种方法是不明显的，还有什么办法来检查这个recursion地列出整个（6TB）文件系统的方法，find最大的inode值？
xfs_db可以帮助你，但需要一些计算。
[root @ system]＃xfs_info / s2b
meta-data = / dev / lxvm / ddn40_s2b isize = 512 agcount = 150，agsize = 52429056 blks
= sectsz = 512 attr = 1，nfs4acl = 0
data = bsize = 4096 blocks = 7814070272，imaxpct = 25
您有150个分配组，编号为0-149，大小为52429056（4096b）个磁盘（200 GB）。
注：我在以下xfs_db上使用-r （只读）。 如果在启用写入的情况下使用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“print count”/ dev / lxvm / ddn40_s2b 完成了 计数= 1349120 count = 1326464 计数= 1376768 count = 1256448 计数= 1184512 计数= 1244352 计数= 1373376 计数= 1303296 count = 0 ...（剩余数量为零）
所以，前面七个部分（或者1400G字节）的inode32限制内有inode。 这个程序可以让你回答你的问题。 它也很快。