I've been working on getting a Windows 8 VM setup with GPU passthru.  I've finally gotten it (mostly) working, and am not enjoying a movie playing on this VM.

 

However, as I'm playing it back, I notice that it's pausing or 'glitching' every couple of seconds.  I've checked several things in my playback chain, but none have worked so far.  Then, I remembered that part of my efforts to get this working resulted in me having to hard boot unRAID; and that it was probably running a parity check.

 

Sure enough, it was running a parity check, and as soon as I cancelled it, playback stopped having problems, and has been playing just fine for the last 10 minutes or so.

 

Conclusion; parity check causes problems with playback of video.

 

Is this a bug, or is this some setup problem of mine, and if so, how might I diagnose and fix my setup issue?

A parity check will take as much CPU as it can use...and it will spin up and continually read simultaneously from EVERY disk.

What you're probably seeing is that your playback software is waiting for more data...and the parity check is sucking up either the databus or the disk drive that you're trying to play the movie from.

 

LOL I just read what I wrote. THat's a pretty inelegant/non-technically accurate way of expressing it, but the sentiment is right.

 

There's some discussion about making the parity check use fewer resources, with the tradeoff being that it will run longer. This discussion was about six weeks ago...I don't know if its in the development queue...as I recall, its not something that can be scripted...it must be part of core unRAID (at least for v5) and therefore requires LImeTech to implement.

 

If you're running separate VM for the the playback and the parity check, can you somehow give less priority to the parity check VM?

Otherwise, do what those of us on v5 do: "Run Parity Check in the wee small hours of the morning."

I was afraid of that.  Seems like a bad design strategy, causing parity check to take all resources, considering most/all want to use the server whether or not parity needs checked or not.

 

As for your comment on using different VM's for this, I'm not sure I understand.  I am running Windows 8 in a VM, trying to playback a video, but unRAID is obviously running as DOM0, so is separated from the VM.  I wouldn't know how to run a parity check in a different VM, as it's part of unRAID.

 

Hopefully this issue gets addressed in the future, to allow us to optionally make a parity check not use all resources.  at least allow us to pause a parity check and/or reschedule it's resumption when the system isn't being used.

While it may not appear to be an optimal design consideration, once you understand the behaviour it's usually easy to avoid it causing issues. For me a parity check takes 10-12 hours. Even if I need to hard reboot for some reason I will usually cancel the parity check and then start it before I go to bed. By morning (or lunch) everything is back and running smooth.

 

When you consider that after a hard reset parity isn't considered valid until you've done the parity check it makes sense to complete it as quickly as possible to ensure your parity is valid. Think about the scenario where the computer crashed on it's own. Would you rather know it's okay in 10-12 hours while keeping the system idle, or 36 hours later because you want to be able to watch movies? The whole point of running UnRAID is parity protection, so personally I want to know I'm protected as quickly as possible (as I am sure the majority do).

While I don't necessarily disagree with you, you said it yourself, you will cancel a parity check after a crash and restart it later.  So, you agree that it's 'better' in some cases to delay the completion of the check, to keep/make the array usable in the meantime.

 

I agree with this thinking, and would prefer an option to put the check into a lower priority, or delayed restart, so that I can used my media without annoying problems, like the one I described.

Sorry, but I disagree and have a hard time seeing UnRAID implement this. The bottom line is you are always working to support the lowest common denominator. At the end of the day UnRAID is there to provide data protection - end of story. Everything else is gravy.

 

Since you can't guarantee that new or non-technical users are going to understand the implications of their actions, as the vendor you need to do your utmost to ensure your product delivers as promised - and that means doing everything possible to ensure parity is valid and usable to recover in the event of a failure.

 

As a user you can choose to cancel and restart a parity check as I described, but the software should never make this decision for you (or let you automate this decision). It has to have your best interests at heart and leave it up to you to risk your content, and since not all users who may play around with settings are going to really understand the associated risk I think UnRAID needs to do what's best for your data, and let you decide to cancel it manually. That way when your data goes to crap you have no one to blame but yourself, and UnRAID avoids any liability.

 

Considering the parity check only kicks in in the event of an unclean shutdown it needs to have top priority on restart - no question. It's up to you then to decide for yourself if you want to introduce risk for convenience.

Okay, we'll have to agree to disagree then.

 

As it stands now, there are 2 choices after a hard-reboot,

 

1. Live with a server that makes using our media a less-than-enjoyable for many hours, which may occur during the evening, when the whole family wants to watch videos, or listen to music (and listen to their complaints), or

 

2. Cancel the parity check.

 

If one wishes to enjoy their media, no matter what time the reboot has occurred, they currently have no real choice, other than option 2.  If they take this option, as I choose to do, and as you also seem to do, then they HAVE TO REMEMBER to re-start the parity check.  I've personally forgotten to do this few times, and have gone with unknown parity situation for days, as a result of choosing to use my media at night, instead of living with a degraded media experience.

 

If there had been an option to pause the parity check (for an amount of time), or reschedule for another time, then I would not have forgotten to restart, and would not have gone for days without confirmed parity.  Or, alternatively, if the parity check would not cause a degraded media experience, then it would not require me to cancel it, and possibly forget to restart it later.

 

So, as you can see, the current situation is not ideal, and could be improved.  Hopefully the great minds behind unRAID will see the potential for improvement.

The other thing to consider is I don't think everyone has the issue where UnRAID is brought to it's knees when a parity check happens. I definitely did with my original low end hardware, but as I've upped the CPU/memory capabilities it seems to be somewhat better (though not always perfect).

 

Also, the parity check only happens after a bad reboot. If you do a clean shutdown and reboot this whole conversation becomes moot as there is no check when you come back up - this is why I was saying it's important for the check to finish - because something went wrong to cause you to hard reboot or the server crashed. Neither are good situations.

 

You are right, being able to delay for X hours would be a good compromise so you don't have to remember to restart it later I've forgotten for a few days as well). I just don't think the default behaviour should change - it should kick-in after a hard down, and then like you said, maybe be able to hit delay for X hours so you sort of get the best of both worlds.