From: Stan Hoeppner <stan@hardwarefreak.com>
To: Ole Tange <ole@tange.dk>
Cc: Peter Grandi <pg@lxra2.for.sabi.co.uk>,
Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: Software RAID checksum performance on 24 disks not even close to kernel reported
Date: Tue, 05 Jun 2012 20:38:10 -0500 [thread overview]
Message-ID: <4FCEB482.3040205@hardwarefreak.com> (raw)
In-Reply-To: <CA+4vN7wVbiHHR=B=QyvSqA+Y9ohiYMZ3xYDokJ+MY0h-AkatxA@mail.gmail.com>
On 6/5/2012 4:17 PM, Ole Tange wrote:
> On Tue, Jun 5, 2012 at 3:09 PM, Peter Grandi <pg@lxra2.for.sabi.co.uk> wrote:
>> [ ... ]
>>
>>>> Good call. But the resync is done before the mkfs.xfs is finished, so
>>>> the time of the copying is not affected by resync.
>>>>
>>>> I re-tested with --assume-clean and as expected it has no impact.
>>
>>> Wanna try CONFIG_MULTICORE_RAID456? :-)
>>
>> That would be intreresting, but the original post reports over
>> 6GB/s for pure checksumming, and around 400MB/s actual transfer
>> rate. In theory there is no need here for multihreading. There
>> may something else going on :-).
>
> I have the feeling that some of you have not experienced md0_raid6
> taking up 100% CPU of a single core. If you have not, please run the
> test on http://oletange.blogspot.dk/2012/05/software-raid-performance-on-24-disks.html
>
> The test requires 10 GB RAM, atleast 2 CPU cores, and takes less than
> 3 minutes to run.
>
> See if you can reproduce the CPU usage, and post your results along
> with the reported checksumming speed reported by the kernel.
There's no need for anyone to duplicate this testing. It's already been
done, problem code identified, and patches submitted, about a week
before you started this thread.
Patches to make md RAID 1/10/5 write ops multi-threaded have already
been submitted (read ops already in essence are multi-threaded). A
patch for RAID 6 has not yet been submitted but is probably in the
works. Your thread comes about a week on the heels of the most recent
discussion of this problem. See the archives.
And specifically, search the list archive for these thread scalability
patches by Shaohua Li. AFAIK the patches haven't been accepted yet, and
it will likely be a while before they hit mainline.
In the mean time, the quickest way to "restore" your lost performance
while still using parity, and not sacrificing lots of platter space, is
to set two spares and create two 11 drive RAID5 arrays. This costs you
one additional disk as a spare. Each md RAID5 thread will run on a
different core, and with only 11 SRDs shouldn't peak a single core,
unless you have really slow cores such as the dual core Intel Atom 330 @
1.60 GHz.
If you need a single file space then layer a concatenated array
(--linear) over the two RAID 5 arrays and format the --linear device
with XFS, which will yield multi-threaded/multi-user parallelism with a
concatenated volume, assuming your workload writes files to multiple
directories. If you think you need maximum single file streaming
performance, then lay a RAID 0 stripe over the two RAID5s and use
whichever filesystem you like. If it's XFS, take care to properly align
writes. This can be difficult using a nested stripe over multiple
parity arrays.
--
Stan
next prev parent reply other threads:[~2012-06-06 1:38 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-04 23:14 Software RAID checksum performance on 24 disks not even close to kernel reported Ole Tange
2012-06-05 1:26 ` Joe Landman
2012-06-05 3:36 ` Igor M Podlesny
2012-06-05 7:47 ` Ole Tange
2012-06-05 11:25 ` Peter Grandi
2012-06-05 20:57 ` Ole Tange
2012-06-06 17:37 ` Peter Grandi
2012-06-05 14:15 ` Stan Hoeppner
2012-06-05 20:45 ` Ole Tange
2012-06-05 3:39 ` Igor M Podlesny
2012-06-05 7:47 ` Ole Tange
2012-06-05 11:29 ` Igor M Podlesny
2012-06-05 13:09 ` Peter Grandi
2012-06-05 21:17 ` Ole Tange
2012-06-06 1:38 ` Stan Hoeppner [this message]
2012-06-05 18:44 ` Ole Tange
2012-06-06 1:40 ` Brad Campbell
2012-06-06 3:48 ` Marcus Sorensen
2012-06-06 11:21 ` Ole Tange
2012-06-06 11:17 ` Ole Tange
2012-06-06 12:58 ` Brad Campbell
2012-06-06 14:11 ` Ole Tange
2012-06-06 16:05 ` Igor M Podlesny
2012-06-06 19:51 ` Ole Tange
2012-06-06 22:21 ` Igor M Podlesny
2012-06-06 22:53 ` Peter Grandi
2012-06-07 3:41 ` Igor M Podlesny
2012-06-07 4:59 ` Stan Hoeppner
2012-06-07 5:22 ` Igor M Podlesny
2012-06-07 9:03 ` Stan Hoeppner
2012-06-07 9:22 ` Igor M Podlesny
2012-06-06 16:09 ` Dan Williams
2012-06-06 19:19 ` Ole Tange
2012-06-06 19:24 ` Dan Williams
2012-06-06 19:26 ` Ole Tange
2012-06-07 4:06 ` Stan Hoeppner
2012-06-07 14:40 ` Joe Landman
2012-06-08 1:23 ` Stan Hoeppner
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=4FCEB482.3040205@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=linux-raid@vger.kernel.org \
--cc=ole@tange.dk \
--cc=pg@lxra2.for.sabi.co.uk \
/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.