linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Freemyer <greg.freemyer@gmail.com>
To: DCox@icc.net
Cc: Erik Slagter <erik@slagter.name>,
	Linux IDE List <linux-ide@vger.kernel.org>
Subject: Re: Readahead with softraid1
Date: Fri, 8 Jul 2005 11:28:37 -0400	[thread overview]
Message-ID: <87f94c37050708082828e37574@mail.gmail.com> (raw)
In-Reply-To: <1120824984.3415.233.camel@vom>

On 7/8/05, Danny Cox wrote:
> Erik,
> 
> On Fri, 2005-07-08 at 14:00 +0200, Erik Slagter wrote:
> > I am using softraid 1 on two sata disks and I'm trying to get the best
> > possible performance. IMHO read actions (if properly addressed) should
> > be split over the two drivers and performed independently. However, I
> > don't notice anything to back this up. The read performance (with the
> > dreaded hdparm) shows read performance on sda,sdb and md0 exactly the
> > same.
> ...
> > What am I doing wrong here???
> 
>         Nothing.  I'll take a shot at answering this one instead of lurking
> this time.  Then, I'll crawl back under my rock.
> 
>         The raid1 driver keeps a "last visited block" for each drive.  This is
> the block number that was most recently read or written by that drive.
> When a read request arrives, the driver examines each drive for the
> nearest last visited block to the one requested.  Guess what?  If the
> read starts with drive sda, then it will *always* be the one chosen to
> service the read in the future, because the last visited block number is
> only one off.  This would only change if there are multiple processes
> performing I/O on the md device.  Then, it may switch to another drive.
> In any case, it will *tend* to stick with the same drive.
> 
>         Did I explain that well, or only muddy the waters?
> 
> --
> Daniel S. Cox
> Internet Commerce Corporation
> 

Interesting.  Unfortunately, I do a lot of sequential reading with
little or no other computer activity and had wondered about the "slow"
speed of RAID 1 on read.

Does anyone know if that a common implementation on Hardware Raid
controllers too?

I have actually been working mostly with 3ware 7000 series cards, so
the md implementation does not affect me, but if that is a common
design then the 3ware card may have a similar algorithm.

Greg
-- 
Greg Freemyer
The Norcross Group
Forensics for the 21st Century

      parent reply	other threads:[~2005-07-08 15:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-08 12:00 Readahead with softraid1 Erik Slagter
2005-07-08 12:05 ` Jens Axboe
2005-07-08 12:16 ` Danny Cox
2005-07-08 13:16   ` Erik Slagter
2005-07-08 13:30     ` Jens Axboe
2005-07-08 13:42     ` Danny Cox
2005-07-08 15:28   ` Greg Freemyer [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=87f94c37050708082828e37574@mail.gmail.com \
    --to=greg.freemyer@gmail.com \
    --cc=DCox@icc.net \
    --cc=erik@slagter.name \
    --cc=linux-ide@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;
as well as URLs for NNTP newsgroup(s).