Hi all,
It's all about the commit 09654ed8a18c ("xfs: check sb_meta_uuid for
dabuf buffer recovery").
IIUC, any XFS buffer will be in an internally consistent state
regardless of whether any other buffer is replaying to it.
Specifically, for a buffer like:
...
bleaf[0].hashval = 0x2e
bleaf[0].address = 0x8
bleaf[1].hashval = 0x172e
bleaf[1].address = 0xa
bleaf[2].hashval = 0x4eccc517
bleaf[2].address = 0x36
bleaf[3].hashval = 0x4eccc519
bleaf[3].address = 0x2a
bleaf[4].hashval = 0x4eccc51a
bleaf[4].address = 0x24
bleaf[5].hashval = 0x4eccc51b
bleaf[5].address = 0x1e
bleaf[6].hashval = 0x4eccc51e
bleaf[6].address = 0xc
bleaf[7].hashval = 0x9133c702
bleaf[7].address = 0x68
bleaf[8].hashval = 0x9133c704
bleaf[8].address = 0x52
bleaf[9].hashval = 0x9133c705
bleaf[9].address = 0
bleaf[10].hashval = 0x9133c706
bleaf[10].address = 0x3c
bleaf[11].hashval = 0x9133c707
bleaf[11].address = 0
btail.count = 12
btail.stale = 2
and then If we skip a buffer replay during log recovery, the buffer
will still be in an internally consistent state. This implies that the
'stale' or 'count' will be consistent with the real count in the
block, meaning it won't trigger the check in xfs_dir3_leaf_check_int.
but the commit 09654ed8a18c ("xfs: check sb_meta_uuid for dabuf buffer
recovery") states that in some scenarios, IIUC, if we skip a buffer
replay during log recovery, the buffer will not be in an internally
consistent state.
What could cause this inconsistency? Are there any potential issues
with the directory block?
Hope my naive question doesn't contaminate your timeline.
Thanks,
Stephen.
