Re: Uncorrectable errors on RAID-1?

[Phillip Susi <psusi@ubuntu.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 12/23/2014 05:09 PM, Chris Murphy wrote:
> The timer in /sys is a kernel command timer, it's not a device
> timer even though it's pointed at a block device. You need to
> change that from 30 to something higher to get the behavior you
> want. It doesn't really make sense to say, timeout in 30 seconds,
> but instead of reporting a timeout, report it as a read error.
> They're completely different things.

The idea is not to give the drive a ridiculous amount of time to
recover without timing out, but for the timeout to be handled properly.

> There are all sorts of errors listed in libata so for all of them
> to get dumped into a read error doesn't make sense. A lot of those
> errors don't report back a sector, and the key part of the read
> error is what sector(s) have the problem so that they can be fixed.
> Without that information, the ability to fix it is lost. And it's
> the drive that needs to report this.

It is not lost.  The information is simply fuzzed from an exact
individual sector to a range of sectors in the timed out request.  In
an ideal world the drive would give up in a reasonable time and report
the failure, but if it doesn't, then we should deal with that in a
better way than hanging all IO for an unacceptably long time.

> Oven doesn't work, so lets spray gasoline on it and light it and
> the kitchen on fire so that we can cook this damn pizza! That's
> what I just read. Sorry. It doesn't seem like a good idea to me to
> map all errors as read errors.

How do you conclude that?  In the face of a timeout your choices are
between kicking the whole drive out of the array immediately, or
attempting to repair it by recovering the affected sector(s) and
rewriting them.  Unless that recovery attempt could cause more harm
than degrading the array, then where is the "throwing gasoline on it"
part?  This is simply a case of the device not providing a specific
error that says whether it can be recovered or not, so let's attempt
the recovery and see if it works instead of assuming that it won't and
possibly causing data loss that could be avoided.

> Any decent server SATA drive should support SCT ERC. The
> inexpensive WDC Red drives for NAS's all have it and by default are
> a reasonable 70 deciseconds last time I checked.

And yet it isn't supported on the cheaper but otherwise identical
greens, or the higher performing blues.  We should not be helping
vendors charge a premium for zero cost firmware features that are
"required" for raid use when they really aren't ( even if they are
nice to have ).


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUn3U5AAoJENRVrw2cjl5RFIQIAJAr86Y5s8RWuL8/We/AlM5Q
JUuZGGaE1IGmMROdUAEzmj78L8lI2U3D95sERDKmd3aJosfpi1SVOExQZebSIqch
hhkLGC0FecxE5VC/67E2wwmfbropSk0mlA5Fbgx8mYf60iUHWcFUkc01kER3JGnd
xMI2jV0UpqVD/gY/a5O7Z7bPeHICQcIyXCN7MAbTMBrDWsYhDACQpij+aNXu5+ke
rCNV5c/VkYFQZ9aaMb6Mxmi9KOkCVv2+kBOsxwqPxlO5s9vKORDhxMp8XeJQEvhU
X2GAgS8r8gSGVdPutekXR1vB+TwhdMxftBWL9jcI1y05Y0z3GcOX+/90S9mrSaU=
=2tIU
-----END PGP SIGNATURE-----