Here is some more xfs_db output, we are in agi 0 (inode allocation group 0)
xfs_db: agi 0
xfs_db: print
magicnum = 0x58414749
versionnum = 1
seqno = 0
length = 4222
count = 64
root = 3
level = 1
freecount = 59
newino = 128
dirino = null
unlinked[0-63] =
which tells us there are 59 free inodes left out of 64
if we go to the root block of the inode free space tree:
xfs_db: addr root # follows the root field of the previous structure
xfs_db: print
magic = 0x49414254
level = 0
numrecs = 1
leftsib = null
rightsib = null
recs[1] = [startino,freecount,free] 1:[128,59,0xffffffffffffffe0]
We see a bit map with 1s representing free inodes. If we compare this
with the good image:
xfs_db: agi 0
xfs_db: addr root
xfs_db: print
magic = 0x49414254
level = 0
numrecs = 1
leftsib = null
rightsib = null
recs[1] = [startino,freecount,free] 1:[128,60,0xfffffffffffffff0]
We see that we have used one more inode in the block, and that the
bitmap has been correctly adjusted to represent the inode being
in use.
The inode number is calculated based on this free space map,
everything is telling us we should have used inode number 132,
but we lost it somewhere between allocating the inode number and
placing it in the directory, the trick is to find out where it
goes missing.
Can you repeat the same experiment, but use a three letter name
for the second inode. One aspect of the directory format is that it
is tightly packed, and in the test case the second inode number is
getting stored starting on an odd byte boundary. This will at least
tell me if this is the problem, or if we are losing it somewhere
earlier.
Here is a hex dump of a directory inode with two entries in it:
00: 494e41ed 01010002 00000000 00000000 00000002 00000000 00000000 00000000
20: 39aab75f 07439e80 39aaaccc 2f330200 39aaaccc 2f330200 00000000 0000001b
40: 00000000 00000000 00000000 00000000 00000002 00000000 00000000 00000061
60: ffffffff 02000000 00800300 30584653 00011d20 04004074 65737400 011d2305
1122 22333333 44444444 11222233 33333344 444444
The numbers represent the following:
1 - name length
2 - an offset field
3 - the name
4 - the inode number
Notice that the inode numbers are immediately following the name field, so the
second one starts on an odd boundary. This example is a little different
from yours since the inode numbers are different.
To get this information out of xfs_db I did this
inode 128 # the root
type data # tell it to format as raw hex
print # print it
>From the ppc disk image I got this:
00: 494e41ed 01010002 00000000 00000000 00000002 00000000 00000000 00000000
20: 39a90ca0 15752a00 39a90c9c 1a39de00 39a90c9c 1a39de00 00000000 0000001b
40: 00000000 00000000 00000000 00000000 00000002 00000000 00000000 00000000
60: ffffffff 02000000 00800300 30584653 00000083 04004074 65737400 00000000
^^ ^^^^^^
inode num = 0
If a three letter name does not work then we are losing the inode number
somewhere earlier and we will have to start instrumenting the code to
find out where.
Steve
|