Re: [PATCH] repair: fix process_rt_rec_dups

[Christoph Hellwig <hch@lst.de>]

On Wed, Nov 08, 2023 at 10:08:27AM -0800, Darrick J. Wong wrote:
> On Wed, Nov 08, 2023 at 06:53:20PM +0100, Christoph Hellwig wrote:
> > search_rt_dup_extent takes a xfs_rtblock_t, not an RT extent number.
> > 
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > ---
> > 
> > What scares me about this is that no test seems to hit this and report
> > false duplicates.  I'll need to see if I can come up with an
> > artifical reproducers of some kind.
> 
> I think you've misread the code -- phase 4 builds the rt_dup tree by
> walks all the rtextents, and adding the duplicates:

Hmm.

So yes, add_rt_dup_extent seems to be called on an actual rtext, but
scan_bmapbt calls search_rt_dup_extent with what is clearly
a fsbno_t.   So something is fishy here for sure..

> So I think the reason why you've never seen false duplicates is that the
> rt_dup tree intervals measure rt extents, not rt blocks.  The units
> conversion in process_rt_rec_dups is correct.

Note that I don't see error with the patch either, so either way the
coverage isn't good enough..