From: David Brown <david.brown@hesbynett.no>
To: Bill Davidsen <davidsen@tmr.com>
Cc: Linux RAID <linux-raid@vger.kernel.org>,
William Thompson <wt@electro-mechanical.com>
Subject: Re: raid 10f2 vs 1 on 2 drives
Date: Sat, 26 May 2012 18:07:06 +0200 [thread overview]
Message-ID: <4FC0FFAA.1020009@hesbynett.no> (raw)
In-Reply-To: <4FBFD78D.1010503@tmr.com>
On 25/05/12 21:03, Bill Davidsen wrote:
> William Thompson wrote:
>> On Wed, May 23, 2012 at 12:36:12AM +0200, David Brown wrote:
>>> On 22/05/12 21:33, William Thompson wrote:
>>>> I understand that raid 10 f2 is slower on writes due to the location
>>>> of the
>>>> 2nd copy. My question is, if lots of writes are performed, could this
>>>> layout wearout the drives quicker than raid 1?
>>>
>>> No, wear is not going to be significantly different.
>>>
>>> You didn't say whether you are talking about hard disks (where
>>
>> Sorry about that (Chief). Yes, I was refering to hard drives.
>>
>>> location makes a difference, but "wear" on the drive motor is
>>> insignificant to the disk's expected lifetime), or flash disks
>>
>> I was thinking about how much more head movement there would be to
>> write the
>> 2nd copy of the data.
>>
> There _is_ no extra head motion. The location of consecutive blocks is
> different on each drive, but as I read the mapping function the distance
> between blocks on the same drive will be about the same, so amount of
> head motion (both number and distance) is the same on each drive, but
> the location of that motion is not the same.
>
> One drive may be seeking at the outer edge of the platter while another
> seeks near the spindle, but there's the same amount of seeking on each.
>
>
That's not the case for "far" layout. When you write a block, it there
will be two copies - one in the first half of one disk (say, disk 1),
and the other in the second half of the other disk (disk 2). The next
sequential block will be written to the first half of disk 2, and the
second half of disk 1 - exactly half a disk away from the first block.
And no matter where the disk head ends up after the write, raid10,far
will always read from the outer half of the disk since it is
significantly faster. (For SSDs it doesn't matter, but then neither
does head positioning.)
Write merging, combining, re-ordering, etc., will minimise this effect,
as will write caches. But there is no doubt that raid10,far sacrifices
write speed a little in order to get the fastest possible read speeds.
For most use-cases, with more reading than writing, this results in the
best overall speed.
next prev parent reply other threads:[~2012-05-26 16:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-22 19:33 raid 10f2 vs 1 on 2 drives William Thompson
2012-05-22 22:36 ` David Brown
2012-05-23 11:25 ` William Thompson
2012-05-25 19:03 ` Bill Davidsen
2012-05-25 19:40 ` Roberto Spadim
2012-05-26 16:07 ` David Brown [this message]
2012-05-26 23:41 ` Bill Davidsen
2012-05-27 0:46 ` keld
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=4FC0FFAA.1020009@hesbynett.no \
--to=david.brown@hesbynett.no \
--cc=davidsen@tmr.com \
--cc=linux-raid@vger.kernel.org \
--cc=wt@electro-mechanical.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).