On 03/15/2014 03:53 PM, Scott D'Vileskis wrote: >> >> This is deliberate, and in my opinion, desirable. Same thing happens >> when doing a check or any kind of rebuild on multiple arrays that use >> partitions on shared underlying devices. If you don't limit the raid >> background activity, the extra seek load on the devices can severely cut >> performance, especially on spinning rust. >> > > If I was doing a 'normal' resync, I would also agree. > > But my point was this... > My raid was doing a --replace of /dev/sdf1 with /dev/sde1 > It was only reading/writing from/to those two devices, not the other > disks in the raid. (i.e. /dev/sd[a-d] were not being used) > The other job I started (dd if=/dev/zero of=/dev/sda2 bs=1M) was only > writing to /dev/sda > > These jobs should be are perfectly capable of running in parallel > without slowing eachother down. Good point. If I were Neil, I'd say "Patch Welcome!". :-) > I think the logic that pauses a resync on 'related' disk activity > should treat a --replace slightly different But I would insist that the solution be generic -- make the existing logic notice that the activity is on unrelated members, so all background activity would benefit from the new algorithm. IMHO. Phil -- 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
