All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jakob Østergaard" <jakob@unthought.net>
To: Kent Borg <kentborg@borg.org>
Cc: Arjan van de Ven <arjanv@redhat.com>,
	Jaime Medrano <overflow@eurielec.etsit.upm.es>,
	linux-kernel@vger.kernel.org
Subject: Re: raid1 performance
Date: Wed, 1 May 2002 18:35:53 +0200	[thread overview]
Message-ID: <20020501183553.D31556@unthought.net> (raw)
In-Reply-To: <Pine.LNX.4.33.0204301411210.4658-100000@cuatro.eurielec.etsit.upm.es> <3CCE9038.F4C830B4@redhat.com> <20020430102148.D4470@borg.org>

On Tue, Apr 30, 2002 at 10:21:48AM -0400, Kent Borg wrote:
> On Tue, Apr 30, 2002 at 01:38:16PM +0100, Arjan van de Ven wrote, very
> roughly: 
> [that RAID 1 is only as fast in reading as the fastest disk because of
> seeking over alternate blocks, and ]
> 
> > The only way to get the "1 thread sequential read" case faster is by
> > modifying the disk layout to be
> > 
> > Disk 1: ACEGIKBDFHJ
> > Disk 2: ACEGIKBDFHJ
> > 
> > where disk 1 again reads block A, and disk 2 reads block B.  To read
> > block C, disk 1 doesn't have to move it's head or read a dummy block
> > away, it can read block C sequention, and disk 2 can read block D
> > that way.
> >
> > That way the disks actually each only read the relevant blocks in a
> > sequential way and you get (in theory) 2x the performance of 1 disk.
> 
> I am confused.  
> 
> Assuming a big enough read is requested to allow a parallelizing to
> two disks, why can't the second disk be told not to read alternate
> blocks but to start reading sequential blocks starting half way up the
> request?

This is *not* as simple as it sounds.  Believe me, I spent a week trying...

However, with ext2 (and other filesystems as well), a large sequential file
read is *not* sequential on the disk.  You should actually see better performance
on RAID-1 than on a single disk for very large reads, becuase some of the lookups
needed (block indirection or whatever) will be run by the "best" disk in the given
situation.

> 
> Also, why does hdparm give me significantly faster read numbers on
> /dev/md<whatever> than it does on /dev/hd<whatever>?  I had assumed
> there was parallelizing going on.  Does this mean I would get a speed
> improvement if I ran my single disk notebook as a single disk RAID 1
> because there is some bigger or better buffering going on in that code
> even without parallelizing?

hdparm is not a good benchmark for this.

Use bonnie, bonnie++, tiotest, or even 'dd' with *huge* files.

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

  reply	other threads:[~2002-05-01 16:35 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-30 12:23 raid1 performance Jaime Medrano
2002-04-30 12:38 ` Arjan van de Ven
2002-04-30 14:21   ` Kent Borg
2002-05-01 16:35     ` Jakob Østergaard [this message]
2002-05-01 17:01       ` Kent Borg
2002-05-01 17:16         ` Justin Cormack
2002-05-01 21:23         ` Bernd Eckenfels
2002-05-02 16:37           ` Jakob Østergaard
2002-06-29  0:01             ` Bernd Eckenfels
  -- strict thread matches above, loose matches on Subject: below --
2004-04-21  5:57 RAID1: Performance Mike Mestnik
2010-07-19 12:14 raid1 performance Marco
2010-07-25 14:58 Marco
2010-07-25 15:19 ` Roman Mamedov
2010-07-26  9:37   ` Marco
2010-07-26 10:24     ` Keld Simonsen
2010-07-26 10:53       ` John Robinson
2010-07-26 11:30         ` Keld Simonsen
2010-07-27 16:10       ` Marco
2010-07-26 11:03     ` Neil Brown
2010-07-27  1:23       ` Leslie Rhorer
2010-07-27 16:10       ` Marco
2010-07-27 22:23         ` Neil Brown
2010-07-28 12:10           ` Marco
2010-07-28 12:24             ` Neil Brown
2010-07-31 15:21           ` Marco
2010-07-31 16:04             ` Keld Simonsen

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=20020501183553.D31556@unthought.net \
    --to=jakob@unthought.net \
    --cc=arjanv@redhat.com \
    --cc=kentborg@borg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=overflow@eurielec.etsit.upm.es \
    /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.