> > 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. I think the logic that pauses a resync on 'related' disk activity should treat a --replace slightly different -- 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
