Re: [PATCH 7/7] xfs: implement block-metadata based data checksums

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Feb 04, 2025 at 06:00:25AM +0100, Christoph Hellwig wrote:
> On Mon, Feb 03, 2025 at 02:20:31PM -0800, Darrick J. Wong wrote:
> > On Mon, Feb 03, 2025 at 10:43:11AM +0100, Christoph Hellwig wrote:
> > > This is a quick hack to demonstrate how data checksumming can be
> > > implemented when it can be stored in the out of line metadata for each
> > > logical block.  It builds on top of the previous PI infrastructure
> > > and instead of generating/verifying protection information it simply
> > > generates and verifies a crc32c checksum and stores it in the non-PI
> > 
> > PI can do crc32c now?  I thought it could only do that old crc16 from
> > like 15 years ago and crc64?
> 
> NVMe has a protection information format with a crc32c, but it's not
> supported by Linux yet.

Ah.  Missed that!

> > If we try to throw crc32c at a device,
> > won't it then reject the "incorrect" checksums?  Or is there some other
> > magic in here where it works and I'm just too out of date to know?
> 
> This patch implements XFS-level data checksums on devices that implement
> non-PI metadata, that is the device allows to store extra data with the
> LBA, but doesn't actually interpret and verify it іn any way.

Ohhhhh.  So the ondisk metadata /would/ need to capture the checksum
type and which inodes are participating.

> > The crc32c generation and validation looks decent though we're
> > definitely going to want an inode flag so that we're not stuck with
> > stable page writes.
> 
> Yeah, support the NOCOW flag, have a sb flag to enable the checksums,
> maybe even a field about what checksum to use, yodda, yodda.

Why do we need nocow?  Won't the block contents and the PI data get
written in an untorn fashion?

--D