Stop Docker when Parity Check starts, start when finished

[cirkator]

Hi, is there a way to stop Plex when the monthly parity check starts and enable Plex when the check is finished?

 

All I can think of is a cron script, but that's not really fancy and could either leave Plex down longer than needed or start it while the parity check is still running.

[RobJ]

I'd like to suggest adding 2 more entries to the Parity Check section of the Scheduler settings page, a script name to run before and a script to run after parity check completes.  That way, requests like the above and others we haven't thought of yet could be satisfied.

[garycase]

... , a script name to run before and a script to run after parity check completes.

 

An excellent idea => this would allow for easy customization of events that are best suspended during parity checks.

 

[... and for those who need help, it would be simple to just post scripts that show how to do various things on an "as requested" basis, without requiring any actual changes to UnRAID]

 

 

[cirkator]

That would be the easiest way to go.

 

I have thought of something along the lines of monitoring the log for the "parity check has finished" entry and then run a script via custom user scripts plugin.

 

But having the ability to run scripts before and after the check being coded into unRAID would be way less hacky :-)

 

And thanks for moving this thread into to appropriate section!

[limetech]

What is the use case?

[JonathanM]

What is the use case?

To modify server behaviour during parity checks. Some people want to stop disk intensive processes so the check completes sooner.

[limetech]

What is the use case?

To modify server behaviour during parity checks. Some people want to stop disk intensive processes so the check completes sooner.

Wouldn't it be better in that case to throttle parity checks back if other disk I/O is occurring?

 

In other words, the feature request is for an imagined solution to a problem - I want to know what the problem is.

[JonathanM]

Wouldn't it be better in that case to throttle parity checks back if other disk I/O is occurring?

 

In other words, the feature request is for an imagined solution to a problem - I want to know what the problem is.

For some, getting the parity check completed in the shortest possible time is the goal. Some of the things I've seen on the forum seem to indicate that while the parity check is underway, other services may suffer, especially with lower powered machines. Personally my parity check is scheduled so that interruptions are minimal, but I can see where scheduling around the check may not be possible.

 

Instead of throttling the parity check I/O and still possibly slowing everything down, they want to single task the parity check to get it over with.

 

Since the same events could be used while a disk rebuild in progress, it would be nice to be able to keep specified services shut down during a rebuild, to reduce the at risk time.

 

All this can be accomplished right now with scripting, but it would be nice to have the scripts called prior and post check automatically.

[garycase]

... Wouldn't it be better in that case to throttle parity checks back if other disk I/O is occurring?

 

That would be a nice feature as well.  As Jonathan noted, it depends on the goal of the user => some folks want their parity check to be "done and over"  (i.e. finish as quickly as possible) -- which is best achieved by essentially halting all other use of the server during that time);  while others want the parity check to simply not interfere with system performance.

 

In the former case, the "before and after" scripts would make it easy to stop and restart those activities that the user doesn't want to be active during the checks;  whereas in the latter case an automated throttling during other activity would automatically ensure performance wasn't an issue.

 

Personally, I'd like the automatic throttling -- I don't really care how long the checks take, as long as they're done.  But I can certainly see the benefit of having the "before and after" scripts available.

 

[Squid]

Given then choice of what to put within unRaid proper, I'd like to see throttling way before start / stop scripts.

 

oh and btw, here's a script to let you execute custom parity check starting / stopping scripts  http://lime-technology.com/forum/index.php?topic=50416.msg511207#msg511207

[garycase]

...

Given then choice of what to put within unRaid proper, I'd like to see throttling way before start / stop scripts.

 

Agree (as my earlier comment implied as well).  Simple fact is that automatic throttling would ensure performance wasn't impacted during the checks -- so they'd be effectively transparent to the users.    If, for some specific reason, you wanted to get a check done as quickly as possible you could manually shut down any background processes (Dockers, VM's) and just not use the array during the check.

[spazmc]

I only do a parity check monthly. It is not a large system and I can only imagine how log it takes on a large system.

What if you could schedule parity checks on a drive by drive basis? or groups of drives? My last parity check was

almost 7 hours on a 2 TB system.

[Squid]

What if you could schedule parity checks on a drive by drive basis? or groups of drives?

Parity checks always (and have to by definition) run against all drives.

 

And as a general rule (unless you are bandwidth limited due to your choice of controllers), a parity check speed isn't significantly affected by the number of drives (ie: 2 drives take as long as 20 drives).  The most important factor in duration is the size of the drives

[spazmc]

  So parity is not on a per drive basis.

 

[Squid]

  So parity is not on a per drive basis.

Never has been, never will be, impossible to be.

[garycase]

  So parity is not on a per drive basis.

 

NO !!  Clearly you don't understand how parity is computed.    You might want to watch this simple tutorial: 

 

[cirkator]

I guess throttling may be a sufficient solution. But a parity check is the only time where all my drives are spinning at the same time, thus creating more heat and during a parity check I let my fans spin at their maximum setting. And they are loud as hell on full speed. That is why I want the parity check to be over as fast as possible.

That's why I want to stop Plex from accessing any disks and slow down my parity check times.

 

But if others want throttling more than the ability to stop dockers/plugins during a parity check, I can live whith that.

 

Squid, will check out your linked script, thank you!

[garycase]

Throttling "solves" the issue most folks might notice ... i.e. degraded system performance during a parity check.

 

It doesn't help ensure a parity check will be done as quickly as possible -- that requires stopping all other array activity.    However, it's easy enough to simply stop any Dockers/VMs that might be using the array before doing a parity check.  In your case you clearly know when you're doing a check, since you spin up the fans to full throttle -- so you just need to also stop those other activities.

 

A script to do the preliminary things and then reset them all after a check is done would be nice -- but I do agree that throttling resolves a much more significant impact.

 

[cirkator]

I will just use the script provided by squid.

As I said, if throttling is of more use to others, I can very much live with squids script.

 

Thanks everyone for your input :-)

[cirkator]

I successfully used Squid's script for the user scripts plugin to achieve what I wanted.

Thanks again!