On Friday February 13, davidsen@xxxxxxx wrote: > NeilBrown wrote: > > Code currently assumes that the devices in a raid6 stripe are > > 0 1 ... N-1 P Q > > in some rotated order. We will shortly add new layouts in which > > this strict pattern is broken. > > So remove this expectation. We still assume that the data disks > > are roughly in-order. However P and Q can be inserted anywhere within > > that order. > > > > Is this a change which could be done on the fly? Because if it is, > there's obviously a huge performance gain to be had in degraded mode. You need to remember which stripes have been changed. So the best you could do is start a raid6->raid5 conversion in the event of a device failure. That would be fairly intrusive while running. But when it has finished you get your performance back. Then do a raid5->raid6 when you get a replacement drive. I don't know that I would recommend this though. NeilBrown > > To clarify, if the order could be changed (raid5 example): > running array 0 1 2 3 4 P > failed device 0 1 F 3 4 P > Leads to a recover of data from the failed device. But if the order > could be changed on the fly, then "recover" would be a one time > operation, recover the entire chunk previously on device 2, write to > device 5(P), change the order so the parity is on the failed device > (can't recover from another fail anyway), and: > remapped stripe 0 1 F 3 4 2 > > Now reads will not cost a recover, and writes hopefully could skip the > parity completely. When the failed device is replaced the rebuild could > restore the chunk order to improve leveling of head motion. > > -- > Bill Davidsen <davidsen@xxxxxxx> > "Woe unto the statesman who makes war without a reason that will still > be valid when the war is over..." Otto von Bismark > -- 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
