linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Brown <david.brown@hesbynett.no>
To: linux-raid@vger.kernel.org
Subject: Re: Multiple SSDs - RAID-1, -10, or stacked? TRIM?
Date: Fri, 11 Oct 2013 10:42:07 +0200	[thread overview]
Message-ID: <5257B9DF.9010000@hesbynett.no> (raw)
In-Reply-To: <20131009123135.GT1779@bitfolk.com>

On 09/10/13 14:31, Andy Smith wrote:
> Hello,
> 
> Due to increasing load of random read IOPS I am considering using 8
> SSDs and md in my next server, instead of 8 SATA HDDs with
> battery-backed hardware RAID. I am thinking of using Crucial m500s.
> 
> Are there any gotchas to be aware of? I haven't much experience with
> SSDs.
> 
> If these were normal HDDs then (aside from small partitions for
> /boot) I'd just RAID-10 for the main bulk of the storage. Is there
> any reason not to do that with SSDs currently?
> 
> I think I read somewhere that offline TRIM is only supported by md
> for RAID-1, is that correct? If so, should I be finding a way to use
> four pairs of RAID-1s, or does it not matter?
> 
> Any insights appreciated.
> 
> Cheers,
> Andy


If you are worried about the reliability of the SSDs, then one
possibility is to throw a couple of HD's into the mix.  I've never done
this, but I think it should work.

Set up a couple of hard disks, capacity at least 8 times an SSD, in a
raid1 pair.  Partition the raid1 into 8 partitions of SSD size.

Then for each pair of SSD, make a triple mirror with the two SSD's, and
a "write-mostly" hard disk raid partition.  All writes will be then get
an extra copy on the hard disk, while reads will always come from the
SSD's, and therefore be at the same low latency and high speed as
before, and will not use up the HD's bandwidth on reads.  And if both
your SSD's die, you have the extra copy on the hard disk.  It will run
like treacle, but it will run.

If you find that the harddisk pair is a bottleneck on write speeds, you
can add a write-intent bitmap to the raid1 sets and enable
"write-behind".  Then writes will be "completed" when the data is on
both SSD's - the writes to the harddisk are queued and will complete
when time allows.  This will greatly reduce the latency on writes, but
of course it means that if the SSD's die while there are pending HD
writes in the queue, the filesystem and applications will think data is
safe on the disk even though it is not yet there.  Only you can decide
the balance here.



  parent reply	other threads:[~2013-10-11  8:42 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
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 [this message]
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=5257B9DF.9010000@hesbynett.no \
    --to=david.brown@hesbynett.no \
    --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).