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
