From: John Robinson <john.robinson@anonymous.org.uk>
To: "Mathias Burén" <mathias.buren@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: mdadm / RAID, a few questions
Date: Fri, 29 Oct 2010 21:22:13 +0100 [thread overview]
Message-ID: <4CCB2CF5.9010402@anonymous.org.uk> (raw)
In-Reply-To: <AANLkTi=QRfQhNy5jDdtq2FsjENZk-ihNas=D4QrS2XMd@mail.gmail.com>
On 29/10/2010 15:18, Mathias Burén wrote:
> Hi,
>
> I've a few questions in relation to mdadm and performance. System
> details follow below:
>
> Intel Atom 330 @ 1.6Ghz (dualcore, HT), 4GB RAM
[...]
> Question 1: I saw that in Linux 2.6.36 (perhaps earlier versions as
> well) you have the kernel config option CONFIG_MULTICORE_RAID456. I
> tried enabling it, booted to 2.6.36 from 2.6.35, and rebuilding of the
> array continued where it left off before reboot. However, the
> performance was abysmal.. around 16MB/s compared to 70MB/s without the
> option turned on. Is this a bug, or is it because the Atom has no
> grunt to speak of?
No, the performance of MULTICORE_RAID456 is abysmal on any CPU. It's an
experimental implementation that doesn't work terribly well. If you're
interested in developing, by all means help, but if not, turn it off.
> Question 2: The array is now recovering since I've grown it to 6 from 4 devices:
> $ cat /proc/mdstat
> Personalities : [raid6] [raid5] [raid4]
> md0 : active raid5 sdf1[0] sde1[5] sdg1[6] sdc1[3] sdd1[4] sdb1[1]
> 5851054080 blocks super 1.2 level 5, 128k chunk, algorithm 2
> [6/6] [UUUUUU]
> [===========>.........] reshape = 57.7% (1126387328/1950351360)
> finish=718.0min speed=19125K/sec
>
> unused devices:<none>
>
> Is there a way to speed it up? /proc/sys/dev/raid/speed_limit_min is
> 100000 (100k), /proc/sys/dev/raid/speed_limit_max is 1000000 (1000k).
No, that's probably about right on something as weak as an Atom. Let it run.
> Question 3: Before I created this RAID5 array I did a quick RAID0 test
> array just for fun, using 2 full devices (not partitions). Now I have
> this:
[...]
Sorry, I don't know the answer to this. I suspect it's to do with
superblock versions, but I don't know - I'm sorry that's not helpful.
Cheers,
John.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-10-29 20:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-29 14:18 mdadm / RAID, a few questions Mathias Burén
2010-10-29 20:22 ` John Robinson [this message]
2010-10-29 20:35 ` Mathias Burén
2010-10-29 20:44 ` Neil Brown
2010-11-04 20:02 ` Mathias Burén
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=4CCB2CF5.9010402@anonymous.org.uk \
--to=john.robinson@anonymous.org.uk \
--cc=linux-raid@vger.kernel.org \
--cc=mathias.buren@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.