On Tue, 10 Jul 2012 14:27:30 -0500 Brassow Jonathan <jbrassow@xxxxxxxxxx>
wrote:
>
> 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...
I came across a bit of code in raid10 recently which would not work properly
in at least some combinations of near>1 and far>1. It might have been only
when 'raid_disks' was not divisible by 'near' - I'd have to check.
Obviously I don't *know* that no-one ever uses a layout like this, but I've
never heard of one. Only rarely do people have 3 copies. Having 4 seems
excessive.
So while I cannot safely change mdadm to reject the combination I have no
concern about never allowing the combination with dm-raid. (are there enough
double-negatives there?).
I think we should keep it simple. Copies + layout. Anything more complex
doesn't - in my opinion - bring any real value at all.
NeilBrown
>
> 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--
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
signature.asc
Description: PGP signature
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
