On 1/31/2025 1:51 AM, Martin K. Petersen wrote: >> There is value in avoiding Copy-on-write (COW) checksum tree on a >> device that can anyway store checksums inline (as part of PI). This >> would eliminate extra checksum writes/reads, making I/O more >> CPU-efficient. Additionally, usable space would increase, and write >> amplification, both in Btrfs and eventually at the device level, would >> be reduced [*]. > I have a couple of observations. > > First of all, there is no inherent benefit to PI if it is generated at > the same time as the ECC. The ECC is usually far superior when it comes > to protecting data at rest. And you'll still get an error if uncorrected > corruption is detected. So BLK_INTEGRITY_OFFLOAD_NO_BUF does not offer > any benefits in my book. I fully agree, there is no benefit if we see it from E2E use case. But for a different use case (i.e., checksum offload), BLK_INTEGRITY_OFFLOAD_NO_BUF is as good as it gets. [Application -> FS -> Block-layer -> Device] I understand that E2E gets stronger when integrity/checksum is placed at the origin of data (application), and then each component collaborates in checking it. But I am not doing E2E here. Call it abuse or creative, but I am using the same E2E capable device to do checksum-offload. If the device had exposed checksum-offload in a different way, I would have taken that route rather than E2E one.
