Re: support for RT data checksums

[Christoph Hellwig <hch@lst.de>]

On Fri, Sep 25, 2026 at 08:52:58AM +1000, Dave Chinner wrote:
> There's new buffer and inode locking in transactions,

Not sure what is new about that.  Tere is a single new transaction,
which logs a single buffer per transaction.  Not exactly new and
dancy.

> 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.  The rationale is pretty clear and documented: it
turns two dependent reads into two reads that work in parallel.

> I'd also like to have the format of the new on disk log item format
> structures clearly documented (because we're going to have to

There is no new log item format, it uses the standard buffer log format.
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.

> validate them) at recovery time, and also have a clear explaination
> of the data vs metadata ordering algorithms that ensures that
> checksums are always valid in crash+recovery situations, especially
> w.r.t. data integrity operations like fsync.

I think I explained it pretty well, but happy to repeat it again:
The zoned write path writes data first, and then records bmap, rmap
and used space tacking in the zone from the I/O completion handler.
The rtcsum code builds on that and only logs that csum from that
same I/O completion handler.  I.e. that data must have reached the
device for the code to log it to be even called, and for devices
with volatile write caches the generic cache flushing must work
(it did not until recently, but the verification of this code found
that bug and it is now fixed upstream).