I ran into a problem the other night.  I have mover scheduled to run daily and a parity check to run monthly.  Well, it turns out that on Saturday night, both were triggered.  So I had mover running at the same time as a parity check.  I didn't realize this until I woke up in the middle of the night and noticed all the drive lights flashing.  I then realized what what was happening.

 

I can't image having both run at the same time is good but I couldn't figure out how to stop mover.  I tried stopping the array but things just seemed to freeze.  Long story made short, I had to power off the server.  Did a parity check on reboot and found 1,600 errors. 

 

I guess in the future I'll only enable mover when I need it but I'm curious to know if there's a way to stop something like this if it happens again.  It would be nice if mover was running, a parity check would know to wait until it's finished or maybe the other way around.

I ran into a problem the other night.  I have mover scheduled to run daily and a parity check to run monthly.  Well, it turns out that on Saturday night, both were triggered.  So I had mover running at the same time as a parity check.  I didn't realize this until I woke up in the middle of the night and noticed all the drive lights flashing.  I then realized what what was happening.

 

I can't image having both run at the same time is good but I couldn't figure out how to stop mover.  I tried stopping the array but things just seemed to freeze.  Long story made short, I had to power off the server.  Did a parity check on reboot and found 1,600 errors. 

 

I guess in the future I'll only enable mover when I need it but I'm curious to know if there's a way to stop something like this if it happens again.  It would be nice if mover was running, a parity check would know to wait until it's finished or maybe the other way around.

 

I think the bolded part is the problem.

 

I don't know for sure, but do not believe that Mover running at the same time as a Parity Check causes problems. (If someone could confirm this that would be great) Though it does likely slow down both processes.

I ran into a problem the other night.  I have mover scheduled to run daily and a parity check to run monthly.  Well, it turns out that on Saturday night, both were triggered.  So I had mover running at the same time as a parity check.  I didn't realize this until I woke up in the middle of the night and noticed all the drive lights flashing.  I then realized what what was happening.

 

I can't image having both run at the same time is good but I couldn't figure out how to stop mover.  I tried stopping the array but things just seemed to freeze.  Long story made short, I had to power off the server.  Did a parity check on reboot and found 1,600 errors. 

 

I guess in the future I'll only enable mover when I need it but I'm curious to know if there's a way to stop something like this if it happens again.  It would be nice if mover was running, a parity check would know to wait until it's finished or maybe the other way around.

 

I think the bolded part is the problem.

 

I don't know for sure, but do not believe that Mover running at the same time as a Parity Check causes problems. (If someone could confirm this that would be great) Though it does likely slow down both processes.

 

Running them together is not a problem. Just takes longer to complete. If the system is too slow for use while both run is another issue. If the mover is scheduled ever night when would you prefer the parity check to run?

Running them both at the same time causes extensive disk thrashing -- which will slow down both processes a LOT.    It's simply not a good idea to do that.

 

If you had access to the web GUI, all you had to do was CANCEL the parity check.

 

To minimize the likelihood of this happening, I'd schedule the Mover to start a few hours earlier than your parity check starts, so Mover should normally be done before the parity check kicks off.

 

To absolutely eliminate any possibility of them both running at the same time, you could either manually invoke Mover (as you noted); or manually invoke the parity check ... which is what I'd do.    You could simply click the "Move Now" button; wait until mover completes (disk activity will stop); and then do a parity check ... then even if the Mover script was invoked during the parity check there wouldn't be anything to move.

 

Running into this exact issue. I was rebuilding a drive after a disk swap and Mover kicked off after a few hours. Got up the this morning expecting to find my disk rebuilt and found an estimate of 60days with only 27% having been completed. The parity speed was in the hundreds of K.

 

I've stopped the parity rebuild and mover is taking ages to move data - 11gig of movie files. I have plenty of CPU, plenty of RAM, Mover uses rsync yes? I guess I'm just antsy because I know my array isn't protected by parity right now but this seems to be taking quite a long time. The read write stats seem to be moving awfully slow and the count on the data used on cache is also slow although I realize it won't move until files are erased from it by Mover. Another file just moved (I've got logging for Mover turned on) and it took 7 minutes to move a file that was under a 1.5gig in size. That seems glacial but I've got no way to figure out where that bottleneck might be Naturally one of the disks that Mover is looking to push files to is the one I've just replaced with a larger disk as the previous was completely full so this likely plays into the problem.

 

It would be helpful if there was some way to halt the Mover process. I suspect a reboot wouldn't harm things and would halt Mover until it's scheduled next. But I cannot currently stop the array because Mover is running and I refuse to do a hard boot with the array in the state it's in. It might also be nice if Mover and Parity weren't allowed to conflict - Parity should take precedence IMO. It makes perfect sense that the two processes thrash the disk subsystem and had I realized the issue I'd have wanted to avoid it for sure!

This is gonna happen with alot of newer people to unRAID - Did to me a long time ago until I figured out what was going on, and my mover is set to go off before parity check

 

But it would be nice for the mover script to check if a parity check is going on and either sleep for a bit and check again, and abort moving for that day completely....

 

Myk

 

It would be helpful if there was some way to halt the Mover process.

 

I am finding the mover not helpful when you need to stop rsync to do other things.

 

The command killall mover does not do it.Neither does killall rsync do it either.I do not want to reset or power off the box.

 

Any clue as to how to shutdown/stop rsync and then trigger the mover to resume where you paused or stopped it?

 

 

How if the mover was to invoke rsync with a high nice value?