Re: [PATCH 08/21] xfs: define the RT data checksum on-disk format

[Eric Biggers <ebiggers@kernel.org>]

On Thu, Sep 24, 2026 at 03:13:59PM -0700, Darrick J. Wong wrote:
> On Thu, Sep 24, 2026 at 11:59:40AM +0200, Christoph Hellwig wrote:
> > Add the on-disk format for the new RT data checksum format.
> > 
> > Keyed off a new read-only compat feature flag, this adds new fields to
> > the superblock to indicate the checksum algorithm used and the size of
> > the blocks containing the checksums.  These new fields reuse the
> > previously reserved padding to make efficient use of the space in the
> > on-disk superblock.
> > 
> > Data checksums are only supported on zoned RT devices, because they
> > require out of places writes to safely update the checksums for file
> > overwrites and a data/metadata split to be able to store the checksums
> > for a group in a file without causing recursion.  This means they can't
> > be supported directly on the data device at all, and only when using
> > the always_cow mode on regular RT devices, but that has no benefit
> > over the zoned allocator which is designed for out of place writes.
> > 
> > The initially supported data checksum algorithms are crc32c and crc64 as
> > specified by NVMe.  Both have extremely fast kernel implementations and
> > the strong data protection guarantees offered by CRC-style algorithms.
> > Both also happen to be support by NVMe for protection information so that
> > the userspace PI passthrough support (once extended to files on file
> > systems) can be reused to expose the checksums to applications and thus
> > provide true end-to-end data integrity.
> 
> And just to play the peanut gallery here, xxhash? <duck>

lib/xxhash.c is kind of outdated and just supports XXH32 and XXH64 with
generic C code.  CRCs of the same width would generally be better.

(CRCs used to be kind of slow.  But with carryless multiplication
instructions, which the kernel uses on most architectures, they're super
fast.  They also have "unlimited" parallelism, unlike XXH32 and XXH64,
which have a data dependency after each 4 words processed.) 

XXH3 could be more competitive and would also offer 128-bit hashes.  But
it seems it would be quite a bit of work to add XXH3 to the kernel.

Unless someone really wants 128-bit checksums for this feature, I think
the two options proposed here (CRC-32C and CRC64-NVME) sound good.

- Eric