All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brown <david.brown@hesbynett.no>
To: Ian Pilcher <arequipeno@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: Multiple SSDs - RAID-1, -10, or stacked? TRIM?
Date: Wed, 09 Oct 2013 18:21:15 +0200	[thread overview]
Message-ID: <5255827B.8090309@hesbynett.no> (raw)
In-Reply-To: <l33q8a$da4$1@ger.gmane.org>

On 09/10/13 16:46, Ian Pilcher wrote:
> On 10/09/2013 07:31 AM, Andy Smith wrote:
>> Any insights appreciated.
> 
> Consider the probable failure mode of an SSD.  An SSD is more likely
> than an HDD to (1) die with absolutely no warning and (2) die due to
> the pattern of data written to it over its lifetime (and the way those
> writes interact with the SSD's controller/firmware).
> 
> #2 in particular means that there is potentially a much higher
> correlation between the failures of SSDs in an array than there is of
> HDDs.  (And #1 means that the consequences will be more catastrophic.)
> 
> I would recommend using SSDs with two different types on controllers.
> 

Do you have any references for these claims?

I would believe that /if/ an SSD was going to die, it is likely to do so
without warning - it is likely to be the controller that has died.  But
I can think of no reason why the controller on an SSD is more likely to
die than the controller on an HD - and HD's have so many more ways to
die (often slowly and noisily).

Modern SSDs are not going to suffer from wear in any realistic
environment.  You have to be intentionally abusive - a decent SSD will
be fine with /years/ of continuous high-speed writes.  Even then, you
will get write failures long before you have read failures.

That leaves firmware bugs as a possible explanation for such worries -
and that also applies to HD's.


But with that aside, having different manufacturers and models for the
two halves of a raid1 pair is not a bad idea regardless of whether you
have SSD's or HD's - it avoids the risk of a double failure due to a bad
production batch.

David


  reply	other threads:[~2013-10-09 16:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-09 12:31 Multiple SSDs - RAID-1, -10, or stacked? TRIM? Andy Smith
2013-10-09 13:00 ` Roberto Spadim
2013-10-09 13:27 ` David Brown
2013-10-09 13:52   ` Roberto Spadim
2013-10-09 14:46 ` Ian Pilcher
2013-10-09 16:21   ` David Brown [this message]
2013-10-09 17:33     ` Ian Pilcher
2013-10-09 18:04       ` Roberto Spadim
2013-10-09 19:08       ` David Brown
2013-10-09 20:35         ` SSD reliability; was: " Matt Garman
2013-10-09 21:17           ` David Brown
2013-10-09 21:46           ` Brian Candler
2013-10-10  6:14     ` Mikael Abrahamsson
2013-10-10 16:18     ` Art -kwaak- van Breemen
2013-10-10  9:15 ` Stan Hoeppner
2013-10-10 20:37   ` Andy Smith
2013-10-11  8:30     ` David Brown
2013-10-11  9:37     ` Stan Hoeppner
2013-10-11  8:42 ` David Brown
2013-10-11 11:00   ` Art -kwaak- van Breemen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5255827B.8090309@hesbynett.no \
    --to=david.brown@hesbynett.no \
    --cc=arequipeno@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.