On 03/15/2014 03:53 PM, Scott D'Vileskis wrote:

quoted

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