On 1/29/2025 8:25 PM, Johannes Thumshirn wrote: > For instance if we get a checksum error on btrfs we not only report in > in dmesg, but also try to repair the affected sector if we do have a > data profile with redundancy. > > So while this patchset offloads the submission side work of the checksum > tree to the PI code, I don't see the back-propagation of the errors into > btrfs and the triggering of the repair code. > > I get it's a RFC, but as it is now it essentially breaks functionality > we rely on. Can you add this part as well so we can evaluate the > patchset not only from the write but also from the read side. I tested the series for read, but only the success cases. In this case checksum generation/verification happens only within the device. It was slightly tricky to inject an error and I skipped that. Since separate checksum I/Os are omitted, this is about handling the error condition in data read I/O path itself. I have not yet checked if repair code triggers when Btrfs is working with existing 'nodatasum' mount option. But I get your point that this needs to be handled.
