On Fri, Feb 23, 2024 at 01:03:01AM +0530, Kanchan Joshi wrote: > - Is there interest in filesystem leveraging the integrity capabilities > that almost every enterprise SSD has. > Filesystems lacking checksumming abilities can still ask the SSD to do > it and be more robust. > And for BTRFS - there may be value in offloading the checksum to SSD. > Either to save the host CPU or to get more usable space (by not > writing the checksum tree). The mount option 'nodatasum' can turn off > the data checksumming, but more needs to be done to make the offload > work. What would be the interface for offloading? E.g. the SSD capability is provided by the async hash in linux crypto API. As you say using the nodatasum option for the whole filesystem would achieve the offloading and not storing the checksums. But other ways would need an interface how to communicate the checksum values back to the filesystem. Dealing with the ahash as interface is not straightforward, may need additional memory for requests and set up of the pages to pass the memory. All that and the latency caused by issuing the request and waiting could be slower than calculating the checksum on CPU. Also the ahash interface is getting less popular, fsverity removed the support not so long ago [1]. [1] https://lore.kernel.org/linux-crypto/20230406003714.94580-1-ebiggers@xxxxxxxxxx/
