On 31.01.25 11:19, Kanchan Joshi wrote: > 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. > So this as of now disables one of the most useful features of the FS, repairing bad data. The whole "story" for the RAID code in the FS is build around this assumption, that we can repair bad data, unlike say MD RAID.
