All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: keld@keldix.com
Cc: Brassow Jonathan <jbrassow@redhat.com>,
	dm-devel@redhat.com, linux-raid@vger.kernel.org, agk@redhat.com
Subject: Re: [PATCH v2] DM RAID: Add support for MD RAID10
Date: Tue, 17 Jul 2012 12:40:59 +1000	[thread overview]
Message-ID: <20120717124059.59d1f8b0@notabene.brown> (raw)
In-Reply-To: <20120716082843.GA30247@www5.open-std.org>

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

On Mon, 16 Jul 2012 10:28:43 +0200 keld@keldix.com wrote:

> On Mon, Jul 16, 2012 at 04:14:31PM +1000, NeilBrown wrote:
> > On Fri, 13 Jul 2012 10:29:23 +0200 keld@keldix.com wrote:
> > 
> > > On Fri, Jul 13, 2012 at 11:27:17AM +1000, NeilBrown wrote:
> > > > On Fri, 13 Jul 2012 03:15:05 +0200 keld@keldix.com wrote:
> > > > 
> > > Well, I have an idea for the odd number of devices:
> > > Have the disks arranged in groups (for N=2 in pairs) and then the last group extended with
> > > the leftover disks in the way it is done now.
> > > 
> > > For 2 copies, this would be a number of pairs, and then a rest group of 3 disks.
> > > For 3 copies, this would be a number of triplets, and then 4 or 5 disks in the last group.
> > 
> > Certainly possible, but it feels clumsy.  I'm not convinced it is a good idea.
> 
> Well, it is for this time only a proposal. I do think it preserves all the benefits of raid10,far
> especially the striping for reading, and I believe it brings redundancy beyond 1 drive up
> from zero for odd-drive arrays to almost raid-1+0 - in my mind this is as good as it can get theoretically.
> In my guts it feels like good design. I am exited about it:-)
> 
> Why do you feel it is clumsy? Because it is not as general as the current code, but it would take a few more lines to do it?
> We do gain a lot of redundancy for say 20 more lines of code.

Yes, because it is not general.   That makes it hard to explain or describe.
That in turn makes mistake easier.

That doesn't mean that I am dead-set against it, but I'm not sure I want to
encourage it.
I don't think RAID10 array with 'odd' numbers of drives are that common in
the first place.
You suggestion would make no difference for 3 devices, a small difference for
5 (4 vulnerable pairs instead of 5) and only becomes significant with 7 or
more devices.  Are people going to make arrays with 7 devices (with 5
vulnerable pairs) instead of 8 devices (with 4 vulnerable pairs)?

> 
> > Maybe that is sensible, but only if someone steps forwards and actually
> > implements the "new" approach.
> 
> I would have hoped you would do it!

In my copious spare time.


> 
> I am not a seasoned kernel hacker like you, but could you point me to the code where
> the sequence of the blocks is done for far and offset? I would think it would only be a few places.
> 
> And then how to handle the two different layouts, and how to do a migration? Where would that be done?

Let's see if Jon comes up with something.

NeilBrown


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

  parent reply	other threads:[~2012-07-17  2:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-12  1:36 [PATCH v2] DM RAID: Add support for MD RAID10 Jonathan Brassow
2012-07-12  6:32 ` NeilBrown
2012-07-12  9:56   ` Alasdair G Kergon
2012-07-12 11:43     ` NeilBrown
2012-07-16 22:06   ` Brassow Jonathan
2012-07-17  2:34     ` NeilBrown
2012-07-17 16:15       ` Brassow Jonathan
2012-07-18  1:11         ` NeilBrown
2012-07-18 14:45           ` Brassow Jonathan
2012-07-12 16:22 ` keld
2012-07-12 19:00   ` Brassow Jonathan
2012-07-13  1:15     ` keld
2012-07-13  1:27       ` NeilBrown
2012-07-13  8:29         ` keld
2012-07-16  6:14           ` NeilBrown
2012-07-16  8:28             ` keld
2012-07-16 22:53               ` Brassow Jonathan
2012-07-17  2:29                 ` NeilBrown
2012-07-17 20:30                   ` Brassow Jonathan
2012-07-17  2:40               ` NeilBrown [this message]
2012-07-18  7:20                 ` keld

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=20120717124059.59d1f8b0@notabene.brown \
    --to=neilb@suse.de \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=jbrassow@redhat.com \
    --cc=keld@keldix.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 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.