On Sun, Sep 30, 2012 at 09:09:08AM +0200, Jakub Hus?k wrote: > Are you sure it's possible to design r10 f2 with the same performance > benefits of current implementation, which will be (in some cases) able > to survive 2-disk failure, when we talk about 4-disk array? IMHO it's > always a trade of between performance and redundancy. When you want to > survive with more failed drives, you can't spread the data and iops > among so many drives. But maybe it's just me trying to use the law of > conservation of energy in a wrong place :), I haven't studied raid > layouts so much. Yes, I am sure we can design a better layout for raid10,far, with the same performance characteristics.. The current layout can already survive 2 disk failures for a 4 disk array, but the chances are only 33 % for surviving the 2 disk crash. The new layout can survive in 66 % of the cases. And the performance is completely the same. That is why the new layout should be the default layout for raid10,far. No performance difference but greatly improved survival chances. > Just to make things clear: I have no problem with the redundancy level > of current r10f2, it was all just about the wrong handling of array failure. Yes, that is understood. Anyway, my take is that both layouts need to be supported by the kernel, for backwards compatibility. We need to have kernel code that can handle all the existing raid10,far arrays already in production. best regards keld > > Thanks > Jakub Hus?k > > On 26.9.2012 11:23, keld@xxxxxxxxxx wrote: > >On Wed, Sep 26, 2012 at 11:08:03AM +0200, keld@xxxxxxxxxx wrote: > >>On Wed, Sep 26, 2012 at 09:59:42AM +0100, John Robinson wrote: > >>>On 26/09/2012 09:28, keld@xxxxxxxxxx wrote: > >>>[...] > >>>>We have discussed earlier how to implement raid10,far that would mean > >>>>better survival chances with more disks failing. This is not implemented > >>>>yet. > >>>No, but even if/when it is, there will still be some combinations of two > >>>discs that you cannot afford to lose. The layout change to try to > >>>improve redundancy will not be generic, as it doesn't work for an odd > >>>number of discs, so the existing layout would have to be retained as an > >>>option. > >>Well, at least for backward compatibility we need an option for the > >>current layout. > >> > >>For odd number of disks, I do think we can improve the chances for more > >>failing disks, as > >>discussed earlier. > >To sum up: for raid10,f2 with odd numbers of disks, you can have a group > >of 3 disks and then > >the rest of the disks ordered in pairs. Thus one disk in each of the pairs > >and one > >disk in the 3-group all could fail and the raid would still be functional. > >This is almost the same improvement as for the even numbered raid10,f2. > >The scheme is easily generalised to raids with more than 2 copies. > > > >Best regards > >Keld > >-- > >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 > -- 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
