Re: [LSF/MM/BPF TOPIC] File system checksum offload

Johannes Thumshirn
2025-02-03T08:04:46Z

On 03.02.25 08:56, Christoph Hellwig wrote:
> On Mon, Feb 03, 2025 at 07:47:53AM +0000, Johannes Thumshirn wrote:
>> The thing I don't like with the current RFC patchset is, it breaks
>> scrub, repair and device error statistics. It nothing that can't be
>> solved though. But as of now it just doesn't make any sense at all to
>> me. We at least need the FS to look at the BLK_STS_PROTECTION return and
>> handle accordingly in scrub, read repair and statistics.
>>
>> And that's only for feature parity. I'd also like to see some
>> performance numbers and numbers of reduced WAF, if this is really worth
>> the hassle.
>
> If we can store checksums in metadata / extended LBA that will help
> WAF a lot, and also performance becaue you only need one write
> instead of two dependent writes, and also just one read.

Well for the WAF part, it'll save us 32 Bytes per FS sector (typically
4k) in the btrfs case, that's ~0.8% of the space.

> The checksums in the current PI formats (minus the new ones in NVMe)
> aren't that good as Martin pointed out, but the biggest issue really
> is that you need hardware that does support metadata or PI. SATA
> doesn't support it at all. For NVMe PI support is generally a feature
> that is supported by gold plated fully featured enterprise devices
> but not the cheaper tiers. I've heard some talks of customers asking
> for plain non-PI metadata in certain cheaper tiers, but not much of
> that has actually materialized yet. If we ever get at least non-PI
> metadata support on cheap NVMe drives the idea of storing checksums
> there would become very, very useful.
>
> FYI, I'll post my hacky XFS data checksumming code to show how relatively
> simple using the out of band metadata is for file system based
> checksumming.
>