On Thu, Jan 30, 2025 at 03:21:45PM -0500, Martin K. Petersen wrote: > So to me, it's a highly desirable feature that btrfs stores its > checksums elsewhere on media. Except for SSDs it generally doesn't - the fact that they are written at the same time means there is a very high chance they will end up on media together for traditional SSDs designs. This might be different when explicitly using some form of data placement scheme, and SSD vendors might be able to place PI/metadata different under the hood when using a big enough customer aks for it (they might not be very happy about the request :)). > But that's obviously a trade-off a user > can make. In some cases media WAR may be more important than extending > the protection envelope for the data, that's OK. I would suggest you > look at using CRC32C given the intended 4KB block use case, though, > because the 16-bit CRC isn't fantastic for large blocks. One thing that I did implement for my XFS hack/prototype is the ability to store a crc32c in the non-PI metadata support by nvme. This allows for low overhead data checksumming as you don't need a separate data structure to track where the checksums for a data block are located and doesn't require out of place writes. It doesn't provide a reg tag equivalent or device side checking of the guard tag unfortunately. I never could come up with a good use of the app_tag for file systems, so not wasting space for that is actually a good thing.
