On Thu, Jan 30, 2025 at 02:45:45PM +0530, Kanchan Joshi wrote: > I would like to propose a discussion on employing checksum offload in > filesystems. > It would be good to co-locate this with the storage track, as the > finer details lie in the block layer and NVMe driver. I wouldn't call this "file system offload". Enabling the data integrity feature or whatever you want to call it is really a block layer issue. The file system doesn't need to get involved at all. Indeed, looking the patch, the only reason why the file system is getting involved is because (a) you've added a mount option, and (b) the mount option flips a bit in the bio that gets sent to the block layer. But this could also be done by adding a queue specific flag, at which point the file system doesn't need to be involved at all. Why would you want to enable the data ingregity feature on a per block I/O basis, if the device supports it? We can debate whether it should be defaulted to on if the device supports it, or whether the needs to be explicitly enabled. It's true that relative to not doing checksumming at all, it it's not "free". The CPU has to calculate the checksum, so there are power, CPU, and memory bandwidth costs. I'd still tend to lean towards defaulting it to on, so that the user doesn't need do anything special if they have hardware is capable of supporting the data integrity feature. It would be enlightening to measure the performance and power using some file system benchmark with and without the block layer data integrity enabled, with no other changes in the file system. If there's no difference, then enabling it queue-wide, for any file system, would be a no-brainer. If we discover that there is a downside to enabling it, then we might decide how we want to enable it. Cheers, - Ted
