Re: [PATCH 0/1] RFC: Unreliable discard performance can cripple RAID1

[Roman Mamedov <rm@romanrm.net>]

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

On Tue, 23 Jun 2015 20:26:12 -0400
Jes.Sorensen@redhat.com wrote:

> From: Jes Sorensen <Jes.Sorensen@redhat.com>
> 
> Neil,
> 
> I have been hitting issues with discard being ridiculously slow on
> arrays with certain typs of SSDs that seem to serialize discard
> processing.
> 
> This is particularly bad as I have seen systems where the IMSM BIOS
> defaults to 4KB chunk size, combined with these badly performing
> drives, it could bump the mkfs on an array from seconds to over 40
> minutes. Most users will stick to the defaults and then hit the
> problem during install without understanding why it goes wrong :(
> 
> The problem is that there is no way to benchmark our way to this or
> somehow test if a drive performs discard at reasonable speed. I
> suggest we take an approach similar to that of RAID456 and default to
> disabling discard, except for the case where the user knows the drives
> are safe.
> 
> Thoughts?

It's very unfortunate if you would cripple all the good SSD models because of
a few bad ones. No one will remember to explicitly put the override to enable
TRIM, or perhaps even know that it gets disabled in md in the first place. The
only thing they will later notice is lowered performance and lifespan of their
SSDs.

Also most importantly, shouldn't this be handled in the lower level (individual
block devices), and not in md? There's already a mechanism to blacklist TRIM
on some specific SSD models (see libata-core), maybe there should be a way to
disable it by default. Or if those SSDs you mentioned really make it unusable,
maybe they should be just blacklisted as well.

-- 
With respect,
Roman

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]