All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brassow Jonathan <jbrassow@redhat.com>
To: NeilBrown <neilb@suse.de>
Cc: dm-devel@redhat.com, linux-raid@vger.kernel.org, agk@redhat.com
Subject: Re: [PATCH] DM RAID:  Add support for MD RAID10 personality
Date: Tue, 10 Jul 2012 14:27:30 -0500	[thread overview]
Message-ID: <5DAA9465-E7B1-4F61-A559-745D653048C2@redhat.com> (raw)
In-Reply-To: <20120704151537.7c91076d@notabene.brown>


On Jul 4, 2012, at 12:15 AM, NeilBrown wrote:

>> 
>> I like your suggestion of changing the parameter names.  I've found the original names somewhat confusing.  ('far_offset' seems to imply to me that the copy would not be the very next stripe, but _offset_ somehow - it seems to have the reverse meaning to me.  I think this comes from the fact that it acts as a modifier to 'far_copy'.)  I toyed with a couple different ways of doing this but figured it was best to just go along.  Anyway, what you are suggesting seems to be:
>> 	raid10_copies <number> (Default: 2)
>> 	raid10_layout <string> (Default: "near"/"adjacent")
>> Where <string> could be "near", "far", "offset" and "some-future-thing".  That seems nice to me and seems to clear up some of the confusion caused by "far_offset" seeming to be a modifier to "far_copies".
> 
> Yes, that is what I'm suggesting.

One problem with this approach is that users can no longer mix and match.  They can't have 2 near copies and 2 far copies, for example.  Perhaps someone might choose this layout for read balancing performance...

The original method didn't allow for two different simultaneous "far" algorithms (because it would add no redundancy unless they were shifted from each other as well as the original), but this new way of specifying makes it worse.

Do you see this as a problem?  If so, we need to find a way to specify the number of copies for each layout /and/ include the potential for "double-shift" vs "single-shift" or some further variant.  One idea I had before was:
	raid10_near_copies <#>
	raid10_far_copies <#>
	raid10_stripe_copies <#>  (similar to far+offset, but still allows for simultaneous "far" w/o "offset")
To allow for the different variants of "shifting", we could have different raid10 variants, like "raid10_2s" or "raid1e_2s" - similar to the extensions on RAID5 ("raid5_ls") that you don't like.  :)

 brassow

  parent reply	other threads:[~2012-07-10 19:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-26 12:03 [PATCH] DM RAID: Add support for MD RAID10 personality Jonathan Brassow
2012-07-04  1:21 ` NeilBrown
2012-07-04  3:20   ` Brassow Jonathan
2012-07-04  5:15     ` NeilBrown
2012-07-04 15:27       ` Jan Ceuleers
2012-07-10 19:27       ` Brassow Jonathan [this message]
2012-07-11  0:08         ` NeilBrown

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=5DAA9465-E7B1-4F61-A559-745D653048C2@redhat.com \
    --to=jbrassow@redhat.com \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /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.