On 3/18/2025 1:37 PM, hch@xxxxxxxxxxxxx wrote: > On Tue, Mar 18, 2025 at 12:36:44PM +0530, Kanchan Joshi wrote: >> Right, I'm not saying that protection is getting better. Just that any >> offload is about trusting someone else with the job. We have other >> instances like atomic-writes, copy, write-zeroes, write-same etc. > > So wahst is the use case for it? I tried to describe that in the cover letter of the PoC: https://lore.kernel.org/linux-btrfs/20250129140207.22718-1-joshi.k@xxxxxxxxxxx/ What is the "thread" model you are > trying to protect against (where thread here is borrowed from the > security world and implies data corruption caught by checksums). Seems you meant threat model. That was not on my mind for this series, but sure, we don't boost integrity with offload. >> >>> IFF using PRACT is an acceptable level of protection just running >>> NODATASUM and disabling PI generation/verification in the block >>> layer using the current sysfs attributes (or an in-kernel interface >>> for that) to force the driver to set PRACT will do exactly the same >>> thing. >> >> I had considered but that can't work because: >> >> - the sysfs attributes operate at block-device level for all read or all >> write operations. That's not flexible for policies such "do something >> for some writes/reads but not for others" which can translate to "do >> checksum offload for FS data, but keep things as is for FS meta" or >> other combinations. > > Well, we can easily do the using a per-I/O flag Right, a per-I/O flag (named REQ_INTEGRITY_OFFLOAD) is what I did in the patch: https://lore.kernel.org/linux-btrfs/20250129140207.22718-2-joshi.k@xxxxxxxxxxx/
