On Tue, Jan 24, 2023 at 10:31:47AM +0800, Qu Wenruo wrote: > I'm wondering what would happen if we submit a read bio containing multiple > sectors, while the block disk driver/firmware has internal checksum and > found just one sector is corrupted (mismatch with its internal csum)? > > For example, we submit a read bio sized 16KiB, and the device is in 4K > sector size (like most modern HDD/SSD). > The corruption happens at the 2nd sector of the 16KiB. > > My instinct points to either of them: > > A) Mark the whole 16KiB bio as BLK_STS_IOERR > This means even we have 3 good sectors, we have to treat them all as > errors. I believe BLK_STS_MEDIUM is the appropriate status for this scenario, not IOERR. The MEDIUM errno is propogated up as ENODATA. Finding specific failed sectors makes sense if a partial of the originally requested data is useful. That's application specific, so the retry logic should probably be driven at a higher level than the block layer based on seeing a MEDIUM error. Some protocols can report partial transfers. If you trust the device, you could know the first unreadable sector and retry from there. Some protocols like NVMe optionally support querying which sectors are not readable. We're not making use of that in kernel, but these kinds of features exist if you need to know which LBAs to exclude for future retries. Outside that, you could search for specific unrecoverable LBAs with split retries till you find them all, divide-and-conquer.
