Re: support for RT data checksums

[Christoph Hellwig <hch@lst.de>]

On Mon, Sep 28, 2026 at 08:59:31AM +1000, Dave Chinner wrote:
> You haven't answered any of my concerns - you're just handwaving
> them away and....
> 
> > > and there's a
> > > whole new buffer cache interface to "read a buffer", and that is
> > > used to open code reading checksum buffers and joining them to a
> > > transaction rather than using the existing xfs_trans_read_buf...()
> > > interfaces.  That in itself needs careful consideration, and clear
> > > justification for why it must be duplicated to stand outside all the
> > > existing BLI/transaction APIs, especially given all the "use the new
> > > async buf read interface to do sync buffer reads" behaviour across
> > > the patchset that could just use the existing interfaces.
> > 
> > I'm not sure what to make of this.  The paragraph almost reads like
> > AI slop to me.
> 
> ... calling the concerns of an experienced engineer "AI slop".

No, I call your meandering writing style slop.

> I'm so disappointed right now.
> 
> You're better than this, Christoph. You know better than to attack
> the person instead of addressing the technical concerns they've
> raised. Calling the concerns of an experienced engineer "AI Slop" is
> also pretty insulting.

Stop this bullshit.   Replay to technical details in the patches if you
want, or wait for the requested document, but don't write weirdly
halluscinated high-level concerns.

> You also know this has a chilling effect - how many people are going
> to be willing to say anything negative about your code, if all they
> get from it is a bunch of insults in return?

They don't that response to technical concerns.  They get detailed
answers like Darrick did.  But that requires actually expressing
technical concerns.

<lots of ramblings snipped>

> > The buffer payload is somewhat new.  It is is the standard rt format,
> > a xfs_rtbuf_blkinfo followed by the real payload, which is an array
> > of checksums.
> 
> Yes, the buffer payload is new, and it uses a new BLF flag that
> indicates it contains regions with some new on-disk format. And
> there are interactions with fsync and data integrity requirements.
> Document them!

No, as explained before and clearly visible even from the full diff
it does not use any new BLF flag.   See why this discussion is so
hard?

> Documenting the design helps -everyone-, not just now, but well into
> the future as well.

And I've not disagree with this.  But next time you think you need one
just request it, and don't generate pages full of rambling and incorrect
text.