linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neil Brown <neilb@suse.de>
To: Jon Nelson <jnelson-linux-raid@jamponi.net>
Cc: linux-raid@vger.kernel.org
Subject: Re: very strange (maybe) raid1 testing results
Date: Thu, 31 May 2007 14:28:29 +1000	[thread overview]
Message-ID: <18014.20205.440811.634850@notabene.brown> (raw)
In-Reply-To: message from Jon Nelson on Wednesday May 30

On Wednesday May 30, jnelson-linux-raid@jamponi.net wrote:
> On Wed, 30 May 2007, Jon Nelson wrote:
> 
> > On Thu, 31 May 2007, Richard Scobie wrote:
> > 
> > > Jon Nelson wrote:
> > > 
> > > > I am getting 70-80MB/s read rates as reported via dstat, and 60-80MB/s as
> > > > reported by dd. What I don't understand is why just one disk is being used
> > > > here, instead of two or more. I tried different versions of metadata, and
> > > > using a bitmap makes no difference. I created the array with (allowing for
> > > > variations of bitmap and metadata version):
> > > 
> > > This is normal for md RAID1. What you should find is that for 
> > > concurrent reads, each read will be serviced by a different disk, 
> > > until no. of reads = no. of drives.
> > 
> > Alright. To clarify, let's assume some process (like a single-threaded 
> > webserver) using a raid1 to store content (who knows why, let's just say 
> > it is), and also assume that the I/O load is 100% reads. Given that the 
> > server does not fork (or create a thread) for each request, does that 
> > mean that every single web request is essentially serviced from one 
> > disk, always? What mechanism determines which disk actually services the 
> > request?
> 
> It's probably bad form to reply to one's own posts, but I just found
> 
> static int read_balance(conf_t *conf, r1bio_t *r1_bio)
> 
> in raid1.c which, if I'm reading the rest of the source correctly, 
> basically says "pick the disk whose current head position is closest". 
> This *could* explain the behavior I was seeing. Is that not correct?

Yes, that is correct.  
md/raid1 will send a completely sequential read request to just one
device.  There is not much to be gained by doing anything else.
md/raid10 in 'far' or 'offset' mode lays the data out differently and
will issue read requests to all devices and often get better read
throughput at some cost in write throughput.

NeilBrown

  reply	other threads:[~2007-05-31  4:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-30  2:52 very strange (maybe) raid1 testing results Jon Nelson
2007-05-31  2:35 ` Richard Scobie
2007-05-31  2:58   ` Jon Nelson
2007-05-31  3:05     ` Jon Nelson
2007-05-31  4:28       ` Neil Brown [this message]
2007-05-31 12:48         ` Bill Davidsen

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=18014.20205.440811.634850@notabene.brown \
    --to=neilb@suse.de \
    --cc=jnelson-linux-raid@jamponi.net \
    --cc=linux-raid@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).