All of lore.kernel.org
 help / color / mirror / Atom feed
From: Danny Cox <DCox@icc.net>
To: Erik Slagter <erik@slagter.name>
Cc: Linux IDE List <linux-ide@vger.kernel.org>
Subject: Re: Readahead with softraid1
Date: Fri, 08 Jul 2005 09:42:40 -0400	[thread overview]
Message-ID: <1120830160.3415.256.camel@vom> (raw)
In-Reply-To: <1120828592.23681.24.camel@localhost.localdomain>

Erik,

On Fri, 2005-07-08 at 15:16 +0200, Erik Slagter wrote:
> > 	Did I explain that well, or only muddy the waters?
> 
> perfect explanation, thanks (and also Jens!).

	Now, I don't know about perfect.... ;-)

> Is this a design decision or is it fundamentaly impossible to split the
> work amongst several drives?  I guess the md driver at least do a
> prefetch of the next block/chunk on the "other" drive(s)?

	If you're doing random reads on the drive, the raid1 logic can really
help.  I don't know of a benchmark off the top of my head that may
demonstrate that, although something from the Samba suite may.  I seem
to recall a program named something like 'tbench', but I don't remember
if that's the random reader or not.

> Now I am still wondering about the readahead issue. What would be a sane
> setting? I guess having both the drives and md doing readahead is not
> optimal?

	The readahead is implemented at the block layer (I think), and I can't
help you with that.  That's two levels (at least) up from the driver.
As I recall, the chain is: driver->md->block->filesystem->vfs, with
possibly the logical disk manager inserted also.  The only detail I seem
to recall is that the md driver changes a READA to a READ (read ahead to
a regular read), or at least it used to.

	Hmm.  I just took a look at 2.6.9 (yes, I'm out of date ;-), and the
function 'read_balance' actually special cases sequential reads, and
reuses the same drive.  I didn't find the READA to READ change that I
remembered, so scratch that.  Looks like Neil has been busy, and I've
been out of touch for awhile.

-- 
Daniel S. Cox
Internet Commerce Corporation


  parent reply	other threads:[~2005-07-08 13:42 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 [this message]
2005-07-08 15:28   ` Greg Freemyer

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=1120830160.3415.256.camel@vom \
    --to=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 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.