Re: support for RT data checksums

[Dave Chinner <dgc@kernel.org>]

On Thu, Sep 24, 2026 at 11:59:32AM +0200, Christoph Hellwig wrote:
> Hi all,
> 
> data checksums provide an additional safeguard against silent data loss.
> 
> In classic XFS they were hard to support because they need to be
> atomically updated with the written data.  The zoned allocator solves
> that problem because it always writes out of place, and the checksums
> can be committed at the same as the metadata linking the newly written
> file data into place.  In theory, a conventional allocator could be used
> in combination with the always_cow option, but there are few upsides of
> this compared to using the zoned allocator.
> 
> Data checksums are stored in per-realtime group files in the metadir,
> similar to other modern RT metadata.  Unlike the checksum design in btrfs
> or some other file system, the checksums are associated with the
> physical blocks, and not with logical data in files.  This reduces the
> mapping overhead, and significantly reduces the write amplification,
> and also avoids duplicate checksums for reflinked files (although those
> are not yet supported with the zoned allocator anyway).
> 
> The initial version provides two checksums algorithms: crc32c and crc64.
> Both of those are cyclic redundancy check algorithms which provide known
> good detection of bit flips that is better than general purpose hash
> functions.  Both are not cryptographic hashes and thus do not provide any
> kind of protection against intentional tampering with the data.
> The crc32c parameters exactly match those use for xfs metadata checksums,
> and also those used by the default btrfs checksum, and the NVMe PI
> formats using crc32c.  The crc64 parameters exactly match those using
> the NVMe PI formats using crc64.  crc32c provides reasonable assurance
> for today's hardware, but might prove limiting for extremely large data
> sets, crc64 fills that void, but probably warrants using > 4k file system
> block sizes to amortize the overhead.

Ok, so this really needs a design doc to explain how it all works,
what the new on-disk format is, scope, constraints, etc, as the
first patch in the series (i.e. in
Documentation/filesystems/xfs/data_checksum_design.rst) so that we
have high level descriptions of the functionality being implemented.
Stuff like why certain crc alrgorithms are supported, how we can add
new ones in the future, constraints of doing so, how different sized
checksums are cleanly supported, etc will make doing such things
much easier.

There's new buffer and inode locking in transactions, 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'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
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.

These are the sorts of details that we need to get right, and it's
really hard to extract the actual design intent from the code that
implements it to determine if the algorithms, ordering and recovery
strategies are solid.

Hence I'd like to see the actual design documented first, then we
can understand and review algorithms, etc, and then verify the code
matches the described algorithms, behaviours, etc. checksums are all
about data integrity, so I'd really like to be able to understand
how it is supposed to work and where it doesn't work. Being forced
to understand design and implementation descisions and constraints
by reverse engineering disjoint chunks of code is not an efficient
use of reviewer time...

Cheers,

-Dave.
-- 
Dave Chinner
dgc@kernel.org