On 24/11/13 22:13, Stan Hoeppner wrote: > On 11/23/2013 11:14 PM, John Williams wrote: >> On Sat, Nov 23, 2013 at 8:03 PM, Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx> wrote: >> >>> Parity array rebuilds are read-modify-write operations. The main >>> difference from normal operation RMWs is that the write is always to the >>> same disk. As long as the stripe reads and chunk reconstruction outrun >>> the write throughput then the rebuild speed should be as fast as a >>> mirror rebuild. But this doesn't appear to be what people are >>> experiencing. Parity rebuilds would seem to take much longer. >> >> "This" doesn't appear to be what SOME people, who have reported >> issues, are experiencing. Their issues must be examined on a case by >> case basis. > > Given what you state below this may very well be the case. > >> But I, and a number of other people I have talked to or corresponded >> with, have had mdadm RAID 5 or RAID 6 rebuilds of one drive run at >> approximately the optimal sequential write speed of the replacement >> drive. It is not unusual on a reasonably configured system. > > I freely admit I may have drawn an incorrect conclusion about md parity > rebuild performance based on incomplete data. I simply don't recall > anyone stating here in ~3 years that their parity rebuilds were speedy, > but quite the opposite. I guess it's possible that each one of those > cases was due to another factor, such as user load, slow CPU, bus > bottleneck, wonky disk firmware, backplane issues, etc. > Maybe this is just reporting bias - people are quick to post about problems such as slow rebuilds, but very seldom send a message saying everything worked perfectly! There /are/ reasons why parity raid rebuilds are going to be slower than mirror rebuilds - delays on one disk reading is one issue, and I expect that simultaneous use of the array for normal work will have more impact on parity raid rebuild times than on a mirror array (certainly compared to raid10 with multiple pairs). I just don't think it is quite as bad as you think. -- 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
