From: Thomas Fjellstrom <thomas@fjellstrom.ca>
To: linux-raid <linux-raid@vger.kernel.org>
Cc: stan@hardwarefreak.com, Phil Turmel <philip@turmel.org>,
Chris Murphy <lists@colorremedies.com>,
Tommy Apel Hansen <tommyapeldk@gmail.com>
Subject: Re: recommended way to add ssd cache to mdraid array
Date: Sat, 9 Feb 2013 23:59:15 -0700 [thread overview]
Message-ID: <201302092359.15280.thomas@fjellstrom.ca> (raw)
In-Reply-To: <50F71BA4.40900@hardwarefreak.com>
On January 16, 2013, Stan Hoeppner wrote:
[snip]
> This is the reason why RAID6 performs so horribly with mixed read/write
> workloads. Using Thomas' example, while he was doing a streaming read
> of a media file and simultaneously doing non-aligned writes from a P2P
> or other application, md is performing a RMW operation during each
> write, adding substantially to the seek burden on the drives. RAID5/6
> use rotating parity, so he also has an extra seek on each of two drives
> occurring, competing with the read seeks of his streaming app. Consumer
> 7.2K drives aren't designed to handle this type of random seek load with
> good performance.
Re-reading through this thread (I have a bit of spare time this weekend), I
finally understood what you wrote there. I'm not normally quite this dense,
and I appologise. The RMW ops and double seek penalties are really quite
harsh.
> If using RAID10 or RAID0 over RAID1, there is no RMW penalty for partial
> stripe width writes, and no extra seek burden for the parity writes, as
> described above for RAID5/6. Thus it doesn't cause the playback stutter
> as the disks can service the read and write requests without running out
> of head seek bandwidth as parity arrays do due to RMW and parity block
> writes.
>
> In summary, with Thomas' old disk system, he would have most likely
> avoided the playback stutter simply by using a non-parity RAID level.
>
> I'm constantly amazed by the fact that so many people here using parity
> RAID don't understand the performance impact of these basic parity RAID
> IO behaviors, and how striping actually works, and the fact that most
> often they're not writing full stripes, and thus not benefiting from
> their spindle count.
I actually do/did have a decent understanding of how raid5 works, and why its
slower than a lay-person would intuit. The extra seeking, the RMW, and for
software raid, the parity calculations. What's happened is I didn't expand
that up to how raid6 obviously works, with an extra parity set interleaved
with the data. *sigh*
Complete face palm moment.
In the future, if I need more performance than what I'll get out of this
setup, I'll move to smaller drives (with ERC, and low URE rates), in raid10.
If I had a couple/few extra bays in this box, I'd be very tempted to go raid10
right now.
As I haven't noticed any stuttering with my "old" 5.5TB (7x1TB) array, I
somehwat doubt I'll notice any on my new 11TB array (7x2TB, switched to raid5,
as with the backup array, I probably don't need/want the extra parity, if two
drives do die at the same time, I still have a backup copy of most/all of the
data, and can just restore it).
Thank you Stan, Chris, Phil, and Tommy for the help and insight. It was all
very helpful.
--
Thomas Fjellstrom
thomas@fjellstrom.ca
next prev parent reply other threads:[~2013-02-10 6:59 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-22 6:57 recommended way to add ssd cache to mdraid array Thomas Fjellstrom
2012-12-23 3:44 ` Thomas Fjellstrom
2013-01-09 18:41 ` Thomas Fjellstrom
2013-01-10 6:25 ` Chris Murphy
2013-01-10 10:49 ` Thomas Fjellstrom
2013-01-10 21:36 ` Chris Murphy
2013-01-11 0:18 ` Stan Hoeppner
2013-01-11 12:35 ` Thomas Fjellstrom
2013-01-11 12:48 ` Thomas Fjellstrom
2013-01-14 0:05 ` Tommy Apel Hansen
2013-01-14 8:58 ` Thomas Fjellstrom
2013-01-14 18:22 ` Thomas Fjellstrom
2013-01-14 19:45 ` Stan Hoeppner
2013-01-14 21:53 ` Thomas Fjellstrom
2013-01-14 22:51 ` Chris Murphy
2013-01-15 3:25 ` Thomas Fjellstrom
2013-01-15 1:50 ` Stan Hoeppner
2013-01-15 3:52 ` Thomas Fjellstrom
2013-01-15 8:38 ` Stan Hoeppner
2013-01-15 9:02 ` Tommy Apel
2013-01-15 11:19 ` Stan Hoeppner
2013-01-15 10:47 ` Tommy Apel
2013-01-16 5:31 ` Thomas Fjellstrom
2013-01-16 8:59 ` John Robinson
2013-01-16 21:29 ` Stan Hoeppner
2013-02-10 6:59 ` Thomas Fjellstrom [this message]
2013-01-16 22:06 ` Stan Hoeppner
2013-01-14 21:38 ` Tommy Apel Hansen
2013-01-14 21:47 ` Tommy Apel Hansen
2013-01-11 12:20 ` Thomas Fjellstrom
2013-01-11 17:39 ` Chris Murphy
2013-01-11 17:46 ` Chris Murphy
2013-01-11 18:52 ` Thomas Fjellstrom
2013-01-12 0:47 ` Phil Turmel
2013-01-12 3:56 ` Chris Murphy
2013-01-13 22:13 ` Phil Turmel
2013-01-13 23:20 ` Chris Murphy
2013-01-14 0:23 ` Phil Turmel
2013-01-14 3:58 ` Chris Murphy
2013-01-14 22:00 ` Thomas Fjellstrom
2013-01-11 18:51 ` Thomas Fjellstrom
2013-01-11 22:17 ` Stan Hoeppner
2013-01-12 2:44 ` Thomas Fjellstrom
2013-01-12 8:33 ` Stan Hoeppner
2013-01-12 14:44 ` Thomas Fjellstrom
2013-01-13 19:18 ` Chris Murphy
2013-01-14 9:06 ` Thomas Fjellstrom
2013-01-11 18:50 ` Stan Hoeppner
2013-01-12 2:45 ` Thomas Fjellstrom
2013-01-12 12:06 ` Roy Sigurd Karlsbakk
2013-01-12 14:14 ` Stan Hoeppner
2013-01-12 16:37 ` Roy Sigurd Karlsbakk
2013-01-10 13:13 ` Brad Campbell
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=201302092359.15280.thomas@fjellstrom.ca \
--to=thomas@fjellstrom.ca \
--cc=linux-raid@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=philip@turmel.org \
--cc=stan@hardwarefreak.com \
--cc=tommyapeldk@gmail.com \
/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.