Perhaps this should go under the "bugs" if it truly is a bug; however, my mover is automatically scheduled to run at 1pm every day. 

 

I just replaced two 4TB drives with 2-12TB drives (yea I know I should have done each in separate steps) so at the current time, I have both drives being emulated.  The data rebuild is currently at the 7.80TB mark; however, I noticed it really slowed down --- the reason, it looks like Mover ran in the background to move data off of my cache drives and placed data in one of the new 12TB drives I just installed still undergoing a parity rebuild.  My question is if a data-rebuild is occuring, why would Mover run while the operation is in progress?

As far as I know that is expected behaviour.

 

The parity Check Tuning plugin gives you the option to automatically pause the array operation while mover is running so that mover runs at maximum speed and then resume the array operation when mover completes.

4 minutes ago, itimpi said:

As far as I know that is expected behaviour.

 

The parity Check Tuning plugin gives you the option to automatically pause the array operation while mover is running so that mover runs at maximum speed and then resume the array operation when mover completes.

Hmm I'll have to look at that.  I guess i always assumed nothing would write to the array if a parity operation was in progress (whether its a check, rebuild, etc.)  In fact, I can't manually click the "MOVE" button because it's grayed out and says "Disabled -- Parity operation is running".  I didn't realize a background process could trump this. 

12 minutes ago, Hawkins12 said:

I guess i always assumed nothing would write to the array if a parity operation was in progress (whether its a check, rebuild, etc.)

It might make sense if mover did not run if it detected that.

 

However you CAN write to the array with normal file operations while an array operation is in progress - it is just that the two operations interact badly from a performance perspective.