Hi,
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.
B) Ignore the error mark the bio as BLK_STS_OK
This means higher layer must have extra ways to verify the contents.
But my concern is, if we go path A), it means after a read bio failure,
we should try read again with much smaller block size, until we hit a
failure with one sector.
IIRC VFS would do some retry, but otherwise the FS/driver layer needs to
do some internal work and hit an error, then they need to do the
split-and-retry manually.
On the other hand path B) seems more straightforward, but the problem is
also obvious. Thankfully most fses are already doing checksum for their
metadata at least.
So what's the common solution in real world for device drivers/firmware?
Path A/B or some other solution?
And should the upper layer do extra split-and-retry by themselves?
I know btrfs scrub code and repair is doing such split-and-retry, but
not 100% sure if this is really needed or helpful in real world.
Thanks,
Qu
