On 9 March 2016 at 23:06, Duncan <1i5t5.duncan@xxxxxxx> wrote: > > Meanwhile, while parity-raid (aka raid56) isn't as bad as it was when > first nominally completed in 3.19, as of 4.4 (and I think 4.5 as I've not > seen a full trace yet, let alone a fix), there's still at least one known > bug remaining to be traced down and exterminated, that's causing at least > some raid56 reshapes to different numbers of devices or recovery from a > lost device to take at least 10 times as long as they logically should, > we're talking times of weeks to months, during which time the array can > be used, but if it's a bad device replacement and more devices go down in > that time... > > Tho hopefully all the really tough problems they would have hit with N- > way-mirroring were hit and resolved with raid56, and N-way-mirroring will > thus be relatively simple, so hopefully it's less than the four years > it's taking raid56. But I don't expect to see it for another year or > two, and don't expect to be actually use it as intended (as a more > failure resistant raid1) for some time after that as the bugs get worked > out, so realistically, 2-3 years. Could the raid5 code could be patched to copy/read instead of build/check parity? In effect I'm wondering if this could be used as an alternative to the current raid1 profile. The bonus being that it seems like it might accelerate shaking out the bugs in raid5. Likewise, would doing the same with the raid6 code in effect implement a 3-way mirror distributed over n-devices? Kind regards, Nicholas -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
