public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jakob Østergaard" <jakob@unthought.net>
To: Bernd Eckenfels <ecki-news2002-04@lina.inka.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: raid1 performance
Date: Thu, 2 May 2002 18:37:58 +0200	[thread overview]
Message-ID: <20020502183758.Q31556@unthought.net> (raw)
In-Reply-To: <20020501130127.A10936@borg.org> <E1731ZL-0005Bl-00@sites.inka.de>

On Wed, May 01, 2002 at 11:23:23PM +0200, Bernd Eckenfels wrote:
> In article <20020501130127.A10936@borg.org> you wrote:
> >  1. Does the OS even know where the heads are in a modern IDE disk?
> 
> >  2. Is "closer" any more finely grained than a binary
> >     positioned/not-positioned?
> 
> > And I guess another question: How much does RAID 1 help and under what
> > kinds of usage?
> 
> No, you just distribute the ready round robin, this means each disk has only
> half the seeks it had before. 

No, this is the way it was done a long time ago.

It turns out to be an incredibly bad idea.  In fact, it is the most CPU-efficient
way of guaranteeing the largest average seek times on your disks  ;)

The RAID-1 code now looks at which disk worked closest to the wanted position
last, and picks that disk for the seek.

> As long as you do not spread continous blocks
> (readahead) stats are good you actually reduce overall seeks. This helps
> actually even if no seek is involved because of the fact that you need to
> wait for the begin of a track to read it.

The "new" code (which is not that new anymore) will allow one disk to keep
on a single sequential read for a long time (eventually it will kick in the
idle disk(s) though).

-- 
................................................................
:   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-02 16:38 UTC|newest]

Thread overview: 9+ 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
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 [this message]
2002-06-29  0:01             ` Bernd Eckenfels

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=20020502183758.Q31556@unthought.net \
    --to=jakob@unthought.net \
    --cc=ecki-news2002-04@lina.inka.de \
    --cc=linux-kernel@vger.kernel.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