Potential issue with a directory block

Potential issue with a directory block

[Stephen Zhang]

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.

Re: Potential issue with a directory block

[Dave Chinner]

On Fri, Mar 29, 2024 at 10:55:29AM +0800, Stephen Zhang wrote:
> 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?

Original state:		count = 12, stale = 2
Change A:		adds entry @ 12
			count = 13, stale = 2
Change B:		removes entry 4
			count = 13, stale = 3
Change C;		adds entry @ 9
			count = 13, stale = 2

So at the end of recovering these individual changes, we have stale
entries at 4 and 11.

Now let's fail to replay Change B. What's the final state when we
replay only A + C over the original buffer? Is it internally
consistent?

However, log recovery should never allow this "silently fail to
recover intermediate change" situation to occur - if it can't
recover change B, it must abort recovery immediately and never
attempt to recover change C....

-Dave.
-- 
Dave Chinner
david@fromorbit.com