在 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@xxxxxxxxxxx/
