From: Florian Philipp <lists@binarywings.net>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] mdadm and raid4
Date: Wed, 04 May 2011 14:39:36 +0200 [thread overview]
Message-ID: <4DC14908.50301@binarywings.net> (raw)
In-Reply-To: <4DC11792.8090909@dotcomltd.ru>
[-- Attachment #1: Type: text/plain, Size: 3877 bytes --]
Am 04.05.2011 11:08, schrieb Evgeny Bushkov:
> On 04.05.2011 11:54, Joost Roeleveld wrote:
>> On Wednesday 04 May 2011 10:07:58 Evgeny Bushkov wrote:
>>> On 04.05.2011 01:49, Florian Philipp wrote:
>>>> Am 03.05.2011 19:54, schrieb Evgeny Bushkov:
>>>>> Hi.
>>>>> How can I find out which is the parity disk in a RAID-4 soft array? I
>>>>> couldn't find that in the mdadm manual. I know that RAID-4 features a
>>>>> dedicated parity disk that is usually the bottleneck of the array, so
>>>>> that disk must be as fast as possible. It seems useful to employ a few
>>>>> slow disks with a relatively fast disk in such a RAID-4 array.
>>>>>
>>>>> Best regards,
>>>>> Bushkov E.
>>>> You are seriously considering a RAID4? You know, there is a reason why
>>>> it was superseded by RAID5. Given the way RAID4 operates, a first guess
>>>> for finding the parity disk in a running array would be the one with the
>>>> worst SMART data. It is the parity disk that dies the soonest.
>>>>
>>>> From looking at the source code it seems like the last specified disk is
>>>> parity. Disclaimer: I'm no kernel hacker and I have only inspected the
>>>> code, not tried to understand the whole MD subsystem.
>>>>
>>>> Regards,
>>>> Florian Philipp
>>> Thank you for answering... The reason I consider RAID-4 is a few
>>> sata/150 drives and a pair of sata II drives I've got. Let's look at
>>> the problem from the other side: I can create RAID-0(from sata II
>>> drives) and then add it to RAID-4 as the parity disk. It doesn't bother
>>> me if any disk from the RAID-0 fails, that wouldn't disrupt my RAID-4
>>> array. For example:
>>>
>>> mdadm --create /dev/md1 --level=4 -n 3 -c 128 /dev/sdb1 /dev/sdc1 missing
>>> mdadm --create /dev/md2 --level=0 -n 2 -c 128 /dev/sda1 /dev/sdd1
>>> mdadm /dev/md1 --add /dev/md2
>>>
>>> livecd ~ # cat /proc/mdstat
>>> Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
>>> md2 : active raid0 sdd1[1] sda1[0]
>>> 20969472 blocks super 1.2 128k chunks
>>>
>>> md1 : active raid4 md2[3] sdc1[1] sdb1[0]
>>> 20969216 blocks super 1.2 level 4, 128k chunk, algorithm 0 [3/2] [UU_]
>>> [========>............] recovery = 43.7% (4590464/10484608) finish=1.4min
>>> speed=69615K/sec
>>>
>>> That configuration works well, but I'm not sure if md1 is the parity
>>> disk here, that's why I asked. May be I'm wrong and RAID-5 is the only
>>> worth array, I'm just trying to consider all pros and cons here.
>>>
>>> Best regards,
>>> Bushkov E.
>> I only use RAID-0 (when I want performance and don't care about the data),
>> RAID-1 (for data I can't afford to loose) and RAID-5 (data I would like to
>> keep). I have never bothered with RAID-4.
>>
[...]
>
> I've run some tests with different chunk sizes, the fastest was
> raid-10(4 disks), raid-5(3 disks) was closely after. Raid-4(4 disks) was
> almost as fast as raid-5 so I don't see any sense to use it.
>
> Best regards,
> Bushkov E.
>
>
>
When you have an array with uneven disk speeds, you might consider using
the --write-mostly option of mdadm:
-W, --write-mostly
subsequent devices lists in a --build, --create, or --add command
will be flagged as 'write-mostly'. This is valid for RAID1 only and
means that the 'md' driver will avoid reading from these devices if at
all possible. This can be useful if mirroring over a slow link.
This should help in concurrent read and write operations because the
kernel will not dispatch read requests to a disk that is already having
trouble managing the write operations.
On another point: Are you sure your disks have different speeds? SATA150
and 300 are no reliable indicator because most HDDs cannot saturate the
SATA port anyway. dd is still the most reliable way to measure
sequential throughput.
Regards,
Florian Philipp
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2011-05-04 12:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-03 17:54 [gentoo-user] mdadm and raid4 Evgeny Bushkov
2011-05-03 21:49 ` Florian Philipp
2011-05-04 6:07 ` Evgeny Bushkov
2011-05-04 7:54 ` Joost Roeleveld
2011-05-04 9:08 ` Evgeny Bushkov
2011-05-04 9:38 ` Joost Roeleveld
2011-05-04 9:59 ` Evgeny Bushkov
2011-05-04 12:39 ` Florian Philipp [this message]
2011-05-04 12:45 ` Florian Philipp
2011-05-04 13:21 ` Evgeny Bushkov
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=4DC14908.50301@binarywings.net \
--to=lists@binarywings.net \
--cc=gentoo-user@lists.gentoo.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