linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Borg Onion <borg.onion@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: RAID1 round robin read support in md?
Date: Mon, 5 Dec 2011 16:33:44 +1100	[thread overview]
Message-ID: <20111205163344.6957df93@notabene.brown> (raw)
In-Reply-To: <CAAs5ODuHAE=K-nbd=YuMq-FL33x-22TM2cnmBHud9mEhwuJFOw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]

On Sun, 4 Dec 2011 15:31:30 -0800 Borg Onion <borg.onion@gmail.com> wrote:

> Hello,
> 
> Is it possible to implement round-robin read support for raid1.c in
> md?  I sure would appreciate the extra speed given my RAID1x3SSD
> setup.  A possible algorithm might go like this:
> 
> 1) Given the RAID1 drives are enumerated 0,1,2
> 2) For each read request, call an atomic increment
> 3) mod the returned value with # of drives (3)
> 4) Use the modulus result as the drive # to read from for this operation
> 
> Part of implementation might look like this:
> 
> uint32_t get_next_read_drive(uint32_t num_drives)
> {
>         static uint32_t op_count;
> 
>         return __sync_fetch_and_add(&op_count, 1) % num_drives;
> }
> 
> I'm making the assumption that the md code is multi-threaded.  This
> implementation won't work on all platforms, others might have to do
> some locking.  The num_drives and drive list enumeration is assumed to
> exclude write-mostly devices.  Temporary balancing fairness errors
> from the num_drives variable changing value (adding or removing of
> drives) should be innocuous given these are just read ops on mirrored
> data.
> 
> Thoughts?

I would suggest using RAID10 if 'far' mode instead.

Then reads are distributed across all your drives just like with RAID0, and
you get to choose the chunk size for distribution.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

      parent reply	other threads:[~2011-12-05  5:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-04 23:31 RAID1 round robin read support in md? Borg Onion
     [not found] ` <CALFpzo48C2-HHgw=iOefdHaAUCwEJfjoiXjq=Ngv62a-0yEpcQ@mail.gmail.com>
     [not found]   ` <CAAs5ODv01LE6HRZjteYYsaMF5stTNv-8pdK9JDP18u4QeNGUOQ@mail.gmail.com>
2011-12-05  3:13     ` Marcus Sorensen
2011-12-05  5:21       ` Borg Onion
2011-12-05  5:53         ` Doug Dumitru
2011-12-05 12:28           ` Roberto Spadim
2011-12-05  5:33 ` NeilBrown [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=20111205163344.6957df93@notabene.brown \
    --to=neilb@suse.de \
    --cc=borg.onion@gmail.com \
    --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).