Re: Uncorrectable errors on RAID-1?

[Phillip Susi <psusi@ubuntu.com>]

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

On 01/03/2015 12:31 AM, Chris Murphy wrote:
> It's not a made to order hard drive industry. Maybe one day you'll
> be able to 3D print your own with its own specs.

And wookies did not live on endor.  What's your point?

> Sticking fingers in your ears doesn't change the fact there's a 
> measurable difference in support requirements.

Sure, just don't misrepresent one requirement for another.  Just
because I don't care about a warranty from the hardware manufacturer
does not mean I have no right to expect the kernel to perform
*reasonably* on that hardware.

> This is architecture astronaut territory.
> 
> The system only has a terrible response for two reasons: 1. The
> user spec'd the wrong hardware for the use case; 2. The distro
> isn't automatically leveraging existing ways to mitigate that user
> mistake by changing either SCT ERC on the drives, or the SCSI
> command timer for each block device.

No, it has terrible response because the kernel either waits an
unreasonable time or fails the drive and kicks it out of the array
instead of trying to repair it.  Blaming the user for not buying
better hardware is not an appropriate response for the kernel failing
so badly to handle commonly available hardware that doesn't behave in
the most ideal way.

> Now, even though that solution *might* mean long recoveries on 
> occasion, it's still better than link reset behavior which is what
> we have today because it causes the underlying problem to be fixed
> by md/dm/Btrfs once the read error is reported. But no distro has 
> implemented this $500 man hour solution. Instead you're suggesting
> a $500,000 fix that will take hundreds of man hours and end user
> testing to find all the edge cases. It's like, seriously, WTF?

Seriously?  Treating a timeout the same way you treat an unrecoverable
media error is no herculean task.

> Ok well I think that's hubris unless you're a hard drive engineer. 
> You're referring to how drives behaved over a decade ago, when bad 
> sectors were persistent rather than remapped, and we had to scan
> the drive at format time to build a map so the bad ones wouldn't be
> used by the filesystem.

Remapping has nothing to do with it: we are talking about *read*
errors, which do not trigger a remap.

> http://www.seagate.com/files/www-content/support-content/documentation/product-manuals/en-us/Enterprise/Savvio/Savvio%2015K.3/100629381e.pdf
>
>  That's a high end SAS drive. It's default is to retry up to 20
> times, which takes ~1.4 seconds, per sector. But also note how it
> says

20 retries on a 15,000 rpm drive only takes 80 milliseconds, not 1.4
seconds.  15,000 rpm / 60 seconds per minute = 250 rotations/retries
per second.

> Maybe you'd prefer seeing these big, cheap, "green" drives have 
> shorter ERC times, with a commensurate reality check with their 
> unrecoverable error rate, which right now is already two orders 
> magnitude higher than enterprise SAS drives. So what if this means 
> that rate is 3 or 4 orders magnitude higher?

20 retries vs. 200 retries does not reduce the URE rate by orders of
magnitude; more like 1% *maybe*.  200 vs 2000 makes no measurable
difference at all.


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

iQEcBAEBCgAGBQJUqhCxAAoJENRVrw2cjl5RhDYH/RLbHXEPyjK4j6u33ElOyS5S
W5/nfiT1ZZjVAFxJwD0y/gt2L61hB1PQdlUjBm2NayExfCXn3sEuccAxvjMDrvsL
dFJOV8G/7GBbUfsD0uBustG5639QGc30bRzuiw/URT77zNf+T6+5SmTPSC3Oaj3j
fCcDdiKCwNcYiUF3/Q3gdh4XVI8wgoABHC2S/GqvRB+FmmqD6Yt6yG50TG5sPBzq
zSUSxWjOPwVinZOlPfCUCFr3buw+yzg5fclcvaNRStJM38gtK0UGgeIHFgCViHtN
0xNRCKWMu3XkfjfOI/cYVor79K4sQlz9K83Ja/UAMrOtopdlKjn9N04oIiPdsbg=
=u/i9
-----END PGP SIGNATURE-----