On 2023/1/24 12:44, Keith Busch wrote:
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.
Thanks a lot, that indeed makes more sense.
The retry for file read is indeed triggered inside VFS, not fs/block/dm
layer itself.
Thanks,
Qu
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.
