From: NeilBrown <neilb@suse.de>
To: Brassow Jonathan <jbrassow@redhat.com>
Cc: 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:34:04 +1000 [thread overview]
Message-ID: <20120717123404.3516b943@notabene.brown> (raw)
In-Reply-To: <544F2898-B9C7-42CD-A0FD-F1DE35C5E628@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3868 bytes --]
On Mon, 16 Jul 2012 17:06:32 -0500 Brassow Jonathan <jbrassow@redhat.com>
wrote:
>
> On Jul 12, 2012, at 1:32 AM, NeilBrown wrote:
>
> >>
> >> @@ -76,6 +80,7 @@ static struct raid_type {
> >> const unsigned algorithm; /* RAID algorithm. */
> >> } raid_types[] = {
> >> {"raid1", "RAID1 (mirroring)", 0, 2, 1, 0 /* NONE */},
> >> + {"raid10", "RAID10 (striped mirrors)", 0, 2, 10, -1 /* Varies */},
> >> {"raid4", "RAID4 (dedicated parity disk)", 1, 2, 5, ALGORITHM_PARITY_0},
> >> {"raid5_la", "RAID5 (left asymmetric)", 1, 2, 5, ALGORITHM_LEFT_ASYMMETRIC},
> >> {"raid5_ra", "RAID5 (right asymmetric)", 1, 2, 5, ALGORITHM_RIGHT_ASYMMETRIC},
> >
> > Initialising the "unsigned" algorithm to "-1" looks like it is asking for
> > trouble.
>
> I'm initializing to -1 because I know it is a value that will fail if not set later in the setup process. I could just as easily choose the default values (near = 2).
I don't much care what value you use as long as it is of the same type as the
variable you assign it to. So maybe UINT_MAX, or maybe '2'.
>
> >
> >> @@ -493,7 +554,7 @@ static int parse_raid_params(struct raid
> >> */
> >> value /= 2;
> >>
> >> - if (rs->raid_type->level < 5) {
> >> + if (rs->raid_type->level != 5) {
> >> rs->ti->error = "Inappropriate argument: stripe_cache";
> >> return -EINVAL;
> >> }
> >
> > This leaves RAID6 out in the cold. Maybe
> > level < 5 || level > 6
> > or !=5 !=6
> > or a switch statement?
>
> Thanks. For some reason I had thought that raid6 had level=5, like raid4... Fixed.
I love consistency ... or at least I think I would if only I could find it
somewhere!
>
>
>
> >> @@ -536,9 +605,25 @@ static int parse_raid_params(struct raid
> >> if (dm_set_target_max_io_len(rs->ti, max_io_len))
> >> return -EINVAL;
> >>
> >> - if ((rs->raid_type->level > 1) &&
> >> - sector_div(sectors_per_dev, (rs->md.raid_disks - rs->raid_type->parity_devs))) {
> >> + if (rs->raid_type->level == 10) {
> >> + /* (Len * Stripes) / Mirrors */
> >> + sectors_per_dev *= rs->md.raid_disks;
> >> + if (sector_div(sectors_per_dev, raid10_copies)) {
> >> + rs->ti->error = "Target length not divisible by number of data devices";
> >> + return -EINVAL;
> >> + }
> >
> > I'm not entirely sure what you are trying to do here, but I don't think it
> > works.
> >
> > At the very least you would need to convert the "sectors_per_dev" number to a
> > 'chunks_per_dev' before multiplying by raid_disks and dividing by copies.
> >
> > But even that isn't necessary. If you have a 3-device near=2 array with an
> > odd number of chunks per device, that will still work. The last chunk won't
> > be mirrored, so won't be used.
> > Until a couple of weeks ago a recovery of the last device would trigger an
> > error when we try to recover that last chunk, but that is fixed now.
> >
> > So if you want to impose this limitation (and there is some merit in making
> > sure people don't confuse themselves), I suggest it get imposed in the
> > user-space tools which create the RAID10.
>
> I have seen what you do in calc_sectors(), I suppose I could bring that in. However, I'm simply trying to find the value that will be preliminarily assigned to mddev->dev_sectors. It is an enforced (perhaps unnecessary) constraint that the array length be divisible by the number of data devices. I'm not accounting for chunk boundaries - I leave that to userspace to configure and MD to catch.
In that case I suggest you keep it out of dmraid.
It might make sense to check that the resulting array size matches what
user-space said to expect - or is at-least-as-big-as. However I don't see
much point in other size changes there.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2012-07-17 2:34 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 [this message]
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
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=20120717123404.3516b943@notabene.brown \
--to=neilb@suse.de \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=jbrassow@redhat.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).