Running unraid 6.5.3, the monthly parity check kicked in. which takes ~20 hours. I see per the unraid ui its at  5.62 TB (70.3 %) going at 145.0 MB/sec.

Which is great but the side effect is that in kodi (nvidia shield) or in mpc-hq on a windows machine that playing a video is painful due to buffering.

It is really bad if you try to seek to different parts in the file.

 

Confirmed that the content is not on the cache drive but already written to the array.

Digging into the share I see that the file in question is on one disk, disk2.

Disk2 is using XFS file system and is a 8tb WD RED drive.

Drive is on a SAS expander (AOC-SASLP-MV8).

 

Looking at the Main > Array Devices table, I can see that the only disk that has any current Reads beside parity is Disk 2.

So obviously disk 2 is being checked against parity.. so limited disk io is the root cause.

 

Is there any sort of a QoS or ability to ionice the parity check process?

 

Edited June 29, 20188 yr by zoggy

Tried copying the file off the nas to my machine locally (1gbe to ssd) to just get by for now. I see the transfer struggling to do 850kb/s.

I do not believe that there is any way in the current unRAID release to mitigate the effect of running the parity check.

 

there is a feature request to allow for partial parity checks to allow the complete check to be spread over several days.    This would be very useful with modern large drives as you could then confine the check to run at periods when the server is not in use.   We have had no feedback from Limetech whether such a feature can/will be implemented but it seems an obvious way to reduce the impact of long parity check times.