linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ian Pilcher <arequipeno@gmail.com>
To: linux-raid@vger.kernel.org
Subject: Re: Multiple SSDs - RAID-1, -10, or stacked? TRIM?
Date: Wed, 09 Oct 2013 12:33:19 -0500	[thread overview]
Message-ID: <l3440m$85s$1@ger.gmane.org> (raw)
In-Reply-To: <5255827B.8090309@hesbynett.no>

On 10/09/2013 11:21 AM, David Brown wrote:
> Do you have any references for these claims?

If you mean real data, then no.  I am simply reasoning (hopefully
rationally) from the nature of the different device types, along with
anecdotes from people that have experienced SSD failures.

> 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).

Agreed.  The interesting thing is that a bunch of less reliable devices
that die slowly and noisily may be collectively more reliable over the
long term than a bunch of more reliable devices that die completely at
the same time.  I.e. does the additional variability in failures created
by the mechanical components of HDDs reduce the correlation of the
failures enough to make the entire array more reliable over some period
of time?

(I would expect this effect to be most pronounced when populating an
array with similar SSDs/HDDs.)

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

Agreed, but see my reasoning above.

> 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.

Is it potentially even more important when using SSDs, though?  I
believe that the answer is yes.

I guess we just have to wait for Google to migrate their entire
infrastructure for SSDs and publish a new study ...

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================


  reply	other threads:[~2013-10-09 17:33 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
2013-10-09 17:33     ` Ian Pilcher [this message]
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='l3440m$85s$1@ger.gmane.org' \
    --to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).