From: David Brown <david.brown@hesbynett.no>
To: linux-raid@vger.kernel.org
Subject: Re: Multiple SSDs - RAID-1, -10, or stacked? TRIM?
Date: Wed, 09 Oct 2013 15:27:45 +0200 [thread overview]
Message-ID: <525559D1.6030507@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
For two hard disks, raid10 (with either f2 or o2 layout - n2 is almost
identical to normal raid1) can be a lot faster than raid1, because you
get the striping for big data (especially large reads), you get the
faster read throughput because your data is on the fast outer edge of
the disk, and your read latency is better because your head movement is
smaller. Your writes are a bit slower because they are scattered about
the disk.
But for two SSDs, raid10 (f2, o2) has far fewer benefits because you
have no head movement - it is only large reads that can be faster. If
you need IOPS - and presumably multiple parallel accesses - this is no
help. raid10 has extra complexity and thus extra latency (which will
not be noticeably with HDs, but might be with SSDs), and limitations on
resizing and reshaping.
Extrapolating to 8 disks, I think therefore 4 sets of raid1 pair is
likely to be faster. As to what you should do with these sets, that
depends on the application. XFS over a linear join might be your best
bet - raid0 will work but you probably want a large chunk size because
you want to avoid striped reads and writes in order to get high IOPs.
Don't worry too much about TRIM if your SSDs are decent and you have
plenty of overprovisioning, but offline TRIM is worth doing when
supported. (Never use online TRIM.)
next prev parent reply other threads:[~2013-10-09 13:27 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 [this message]
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
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=525559D1.6030507@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 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.