Hi Tejun,
Il 17-08-2017 14:48 Tejun Heo ha scritto:
Recovered errors aren't reported as IO errors and at least from link
state proper there's no way for the driver to tell apart link
glitches and buffer-erasing power issues.
Ok, so *this* is the root cause of the problem: libata not identifying
spurious link renegotiations vs brief powerloss/powerup events. Out of
curiosity: is this a SATA-specific problem (ie: in the SATA
specification), or even SAS disks are affected?
> - why the scsi midlevel does not respond to a power loss event by
> immediately offlining the disks?
Because we don't wanna be ditching disks on temporary link glitches,
which do happen once in a while.
Any chances to report I/O errors to the upper layers *without* offlining
the device? In this manner, upper layers (ie: MDRAID) can act in a more
informate way. For example: single disk device will simple retry the
failed operation, while MDRAID can take the "badblocks" code path to
deal with the error.
So, the right way to deal with the problem probably is making use of
the SMART counter which indicates power loss events and verify that
the counter hasn't increased over link issues. If it changed, the
device should be detached and re-probed, which will make it come back
as a different block device. Unfortunately, I haven't had the chance
to actually implement that.
This is a very good idea, maybe I can implement it in userspace with a
simple, fast polling scheme (for example, each 60 seconds). Such a
polling would not prevent all corruption scenarios, but will at least
timely inform the user.
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@xxxxxxxxxx - info@xxxxxxxxxx
GPG public key ID: FF5F32A8
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
