Can this be amended to include the ability to postpone an automatic parity check?  i.e. if an unclean shutdown causes a parity check to be started, but I need to use the array, I don't want to cancel the check, just pause until 1am to continue while I'm asleep; for example.

Just cancel the check -- then Start a check when you're not going to need the server for a few hours (i.e. when you're going to bed).

 

Just cancel the check -- then Start a check when you're not going to need the server for a few hours (i.e. when you're going to bed).

 

But my parity checks take 20-30 hours. If one starts at midnight, I'd like to be able to pause it 16 hours later and then have it resume and be done in just a few more hours.  That's Justin's point too.

But my parity checks take 20-30 hours.

 

That's a very long time for a parity check.  Is this an older system with IDE drives (or PCI SATA cards) ??

 

The planned change to automatically throttle parity checks to minimize interference with other server activity should resolve this without the need for a "Pause" button.

 

But my parity checks take 20-30 hours.

 

That's a very long time for a parity check.  Is this an older system with IDE drives (or PCI SATA cards) ??

 

The planned change to automatically throttle parity checks to minimize interference with other server activity should resolve this without the need for a "Pause" button.

 

Yeah, it's not normally that slow, but I'm preclearing two drives and copying one 2 TB drive to another via rsync at the same time, plus a couple of users streaming.  My 4 TB is finishing in almost 24 hours exactly.  Still, it would be nice to pause and resume a parity rebuild.

 

Yes, Parity playing 'nice' would be a mostly suitable alternative.

Just cancel the check -- then Start a check when you're not going to need the server for a few hours (i.e. when you're going to bed).

 

I've done this 4 times since I've owned unRAID, and all 4 times, I've forgotten to restart it when I went to bed, and it's taken an average of about 3 days for me to realize I'd forgotten, and to start it again.

 

If I could just 'pause until some time, or pause for xx hours', I would not have to remember; which I just don't do.

Parity check/sync "auto-throttling" will probably be easier... and possibly accomplish two goals. 

I.E.  the need in preserving bandwith for foreground usage and finishing a parity check in a reasonable time without being forgotten.

 

http://lime-technology.com/forum/index.php?topic=34656.0

 

I.E. a slower parity check while the system is being utilized thus only utilizing background cpu cycles (and completing the parity check process).

 

I've seen this in action and used this to my advantage with regular linux software raid.

Since it's already been done, I'm sure logic could be borrowed to implement this faster.

 

As far a postponing an automatic parity check manually.

 

An option exists to do this via cron and at.

Example:

echo '/root/mdcmd check NOCORRECT' | at 1am

 

Maybe someone could write a front end for this so you don't have to bend over and drop to the command line!

(grin).

 

 

perhaps including an option to use at to submit an 'unscheduled' parity check in the Scheduled parity check option.

i.e. Scheduled parity check

http://lime-technology.com/forum/index.php?topic=34418.0

 

and a somewhat working example.

 

root@unRAID: # echo 'logger /root/mdcmd check NOCORRECT' | at 1am

warning: commands will be executed using /bin/sh

job 2 at Wed Sep  3 01:00:00 2014

 

root@unRAID: # at -l

2      Wed Sep  3 01:00:00 2014 a root

 

root@unRAID: #

tail /var/log/syslog

Sep  2 23:30:01 unRAID kernel: mdcmd (1003): set md_write_method 0

Sep  2 23:30:01 unRAID kernel:

Sep  3 01:00:00 unRAID logger: /root/mdcmd check NOCORRECT

 

keep in mind, my test shows that it was scheduled and ran the logger command which just printed what was on the command line.

 

for a real adhoc scheduled parity check, you need to take out the logger reference in the command line above.

auto-throttling would be fine, as long as it works well.  My reason for postponing is that it makes using the server for streaming useless.  if the throttling doesn't fix this completely, without issue, I'll still want to postpone.

 

if we don't see something on this in the next couple months, I'll see if I can figure out a way to implement your cron job.  Thanks for that!

Really need this feature as well. Either a pause/resume (minimum, requires manual interaction) or an automatic throttle for it (would be the best). When streaming with plex with roku the roku with say reloading over and over again when parity check is running for most movies.

Maybe this is unRAID's way of telling you to read a book, ride a bike, feed the duck, etc etc. 

To add another feature, it would also be nice if a parity check was run during idle times.

My server is not running 24/7. But it often runs half a day or more while it is used for maybe 2-3 hours of movie watching or even less if the kids watch their comics.

Why not checking parity when idling?

 

Of course this means that parity checks have to be interruptable/resumable from the last known posittion.

I have an auto_sleep script working and as soon as all conditions are met, the parity check needs to

stop to let the server go down.

 

What is your opinion?

I'd also like the option to have a scheduled parity check stop selected plugins/containers/VMs.  i.e. anything that scans, or copies, or moves (SB, CP, NZBget, rsync jobs etc) to disks can be stoped whkile a aprity check is run and then it can restart the components it stopped.