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

Qu Wenruo
2025-02-03T23:17:29Z

在 2025/2/3 23:57, Kanchan Joshi 写道:
> On 2/3/2025 1:46 PM, Qu Wenruo wrote:
>>> ell 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.
>>
>> You forgot the csum tree COW part.
>>
>> Updating csum tree is pretty COW heavy and that's going to cause quite
>> some wearing.
>>
>> Thus although I do not think the RFC patch makes much sense compared to
>> just existing NODATASUM mount option, I'm interesting in the hardware
>> csum handling.
>
> But, patches do exactly that i.e., hardware cusm support. And posted
> numbers [*] are also when hardware is checksumming the data blocks.
>
> NODATASUM forgoes the data cums at Btrfs level, but its scope of
> control/influence ends there, as it knows nothing about what happens
> underneath.
> Proposed option (DATASUM_OFFLOAD) ensures that the [only] hardware
> checksums the data blocks.

My understanding is, if the hardware supports the extra payload, it's
better to let the user to configure it.

Btrfs already has the way to disable its data checksum. It's the end
users' choice to determine if they want to trust the hardware.

The only thing that btrfs may want to interact with this hardware csum
is metadata.
Doing the double checksum may waste extra writes, thus disabling either
the metadata csum or the hardware one looks more reasonable.

Otherwise we're pushing for a policy (btrfs' automatic csum behavior
change), not a mechanism (the existing btrfs nodatacsum mount
option/per-inode flag).

And inside kernels, we always provides a mechanism, not a policy.

Thanks,
Qu
>
> [*]
> https://lore.kernel.org/linux-block/20250129140207.22718-1-joshi.k@samsung.com/