Stop Docker when Parity Check starts, start when finished


Recommended Posts

... , 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]

 

 

Link to comment

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!

Link to comment

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.

Link to comment

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.

Link to comment

... 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.

 

Link to comment

...

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.

Link to comment

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

Link to comment

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!

Link to comment

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.

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.