linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Keld Jørn Simonsen" <keld@keldix.com>
To: Iordan Iordanov <iordan@cdf.toronto.edu>
Cc: NeilBrown <neilb@suse.de>, b2 <b2@playtime.bg>,
	linux-raid@vger.kernel.org
Subject: Re: debian software raid1
Date: Sat, 23 Apr 2011 16:23:03 +0200	[thread overview]
Message-ID: <20110423142302.GA17484@www2.open-std.org> (raw)
In-Reply-To: <4DB217B2.8090904@cdf.toronto.edu>

On Fri, Apr 22, 2011 at 08:05:06PM -0400, Iordan Iordanov wrote:
> Hi Neil,
> 
> On 04/22/11 18:12, NeilBrown wrote:
> >This is not correct.  RAID10-n2 on 2 drives is exactly the same layout and
> >very nearly the same speed as RAID1 on 2 drives.  (I say 'very nearly' only
> >because the read-balancing code is a little different and might have 
> >slightly
> >different results).

Well, I think it has some significantly different results with the
different load balancing algorithms. For example the one reported in
this thread. Also other bemchmarks indicate this.

> >Or have you measured these two and found an actually difference?  That 
> >would
> >certainly be interesting.
> 
> The difference that I see is probably 100% due to the different read 
> balancing algorithm. When I start two dd processes reading from two 
> separate partitions on the RAID (just so there are no buffers screwing 
> up my results), with RAID1, I see less than one drive worth of 
> sequential read speed for the two dd processes combined.
> 
> On the other hand, with RAID10 I see the two drives being utilized 
> fully, and I get one drive worth of sequential read speeds for each dd 
> process, or a total of two drives worth of read speed for the two dd 
> processes.
> 
> The numbers were something like this:
> 
> - Single drive speed: ~130MB/s sequential read.
> - Two simultaneous dd sequential reads with RAID1, bs=1024k: ~40MB/s per dd.
> - Two simultaneous dd sequential reads with RAID10, bs=1024k: ~130MB/s 
> per dd.
> 
> That's what I meant by better sequential reads, but perhaps I should try 
> to phrase it more precisely.
> 
> >RAID10-f2 will give faster sequential reads at the cost of slower writes.

The writes will not be much slower, maybe 3 % slower, and in some cases
faster, according to some benchmarks.

> I am not sure what RAID10-f2 on a two disk setup will look like, but I 
> like the idea of the drives being identical, and in the worst case, 
> being able to pull one drive, zero the superblock, and be left with a 
> drive with intact data, which only RAID10-n2 can give, if I am not mistaken.

Yes, RAID10-far and RAID10-offset will not do that. However both
RAID10-far and RAID10-offset will be able to run in degraded mode with
just one disk, and with all data intact.

raid10-far will perform similarily to raid10-near with 2 dd'sC, also a
near 100 % utilization of both drives. however, with just 1 dd,
raid10-far wil also give almost 100 % utilization on bothe drives, while
raid10-near will give 100 % on one drive and 0 % on the other drive (I
think). Also when you ar doing multiple IO, RAID10-far will tend to give
you speeds for an additional sequential read above the speed of a single
drive - none of the other MD raid1/10 formats would do that. 


> Just to follow up on our discussion on Grub v2 and booting from a RAID 
> device. I discovered that if I allow Grub to use UUID, occasionally, it 
> would try to mount a raw device for root instead of the RAID device. 
> Apart from the nuisance, this would probably cause mismatch_cnt to be 
> non-zero!! (heh heh). At any rate, the guide reflects how I deal with 
> that - by turning off the use of UUIDs.
> 
> Many thanks for taking a look at the guide and sharing your thoughts! 
> Please let me know if you still think I should change that part where I 
> say that RAID10 gives me faster sequential reads, and what you would say 
> instead.

best regards
keld

      parent reply	other threads:[~2011-04-23 14:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-19 12:12 debian software raid1 b2
2011-04-19 12:25 ` Mathias Burén
2011-04-19 16:03   ` Iordan Iordanov
2011-04-19 21:10     ` Gordon Henderson
2011-04-19 21:33       ` Steven Haigh
2011-04-19 22:01         ` Roberto Spadim
2011-04-19 22:05           ` Mathias Burén
2011-04-19 22:51     ` NeilBrown
2011-04-20  0:33       ` Joe Landman
2011-04-20  1:12         ` NeilBrown
2011-04-20 14:59           ` Iordan Iordanov
2011-04-20 14:51         ` Iordan Iordanov
2011-04-21  6:15           ` Luca Berra
2011-04-21 14:50             ` Iordan Iordanov
2011-04-22  5:59               ` Luca Berra
2011-04-22 19:19                 ` Iordan Iordanov
2011-04-22 19:28                   ` Mikael Abrahamsson
2011-04-23  0:07                     ` Iordan Iordanov
2011-04-20 10:28       ` Asdo
2011-04-20 12:40         ` NeilBrown
2011-04-23  8:33     ` Jan Ceuleers
2011-04-22 19:21 ` Iordan Iordanov
2011-04-22 22:12   ` NeilBrown
2011-04-23  0:05     ` Iordan Iordanov
2011-04-23 12:54       ` David Brown
2011-04-23 14:23       ` Keld Jørn Simonsen [this message]

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=20110423142302.GA17484@www2.open-std.org \
    --to=keld@keldix.com \
    --cc=b2@playtime.bg \
    --cc=iordan@cdf.toronto.edu \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /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).