2

Some of my users have had trouble with software (on Scientific Linux) that cannot list directory contents when accessing an XFS filesystem mounted with the "inode64" option. So I have copied the data to a freshly created XFS filesystem without this option.

Unfortunately during the process of switching round the filesystems I inadvertently mounted the new filesystem briefly with the inode64 option. I noticed the mistake quickly and unmounted it, and I have checked that there are no files with a modification time later than the error occurred.

But is there any way inodes above the 32-bit limit could have been created without this being apparent from file modification times, and is there any way to check this short of listing the entire (6 TB) filesystem recursively and finding the maximum inode value?

Ben
  • 153
  • 2
  • 10
  • Errr "copied the data" -- just recreate the filesystem and copy again? (I know it doesn't address the problem but it's a really fast solution) – serverhorror Sep 19 '11 at 17:05
  • Thanks. That's the simplest solution and hence probably the best, but I was hoping there would be some check I could do that would be even faster than copying 6 TB of data. – Ben Sep 20 '11 at 09:17

1 Answers1

4

xfs_db can help you here, but it takes a little calculation.

[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

you have 150 allocation groups numbered 0-149, they are 52429056 (4096b) blks (200 Gbytes) in size.

NOTE: I use -r (read only) on the following xfs_db. You can really mess up your filesystem if you use xfs_db with write enabled. You can also do some useful stuff. Only enable writing with xfs_db if you intend to write on the filesystem. Writing to a mounted filesystem could end up in a race with the OS.

For each allocation group's inode section (agi) print out the number of inodes in the section:

[root@system]# for i in `seq 0 149`
lou $ do
lou $ xfs_db -r -c "agi $i" -c "print count" /dev/lxvm/ddn40_s2b 
lou $ done
count = 1349120
count = 1326464
count = 1376768
count = 1256448
count = 1184512
count = 1244352
count = 1373376
count = 1303296
count = 0
... (remaining counts were zero)

so, the first seven sections (or 1400 Gbytes) had inodes in them, within the inode32 limit. This procedure allows you to answer your question. It's pretty fast, too.

Frederik
  • 3,359
  • 3
  • 32
  • 46
Scott
  • 56
  • 2