Using the default mover script in the latest beta with:

 

* */2 * * *

 

In the mover schedule box.

 

Does this mean it will run every two hours?

 

Thanks,

CR

I would use:

0 */2 * * *

 

Run on the hour, every 2 hours (i.e. 2:00am, 4:00am, 6:00am, etc.)

Ok, I tried that, I don't like it.

 

Maybe we can try a different tack.

 

Is there a way of changing/running the script on sleep/array shutdown?

 

That way whatever happens it doesn't need to be timed as it will do it at the end of a day.

Ok, I tried that, I don't like it.

Thought you might not

 

Maybe we can try a different tack.

 

Is there a way of changing/running the script on sleep/array shutdown?

 

That way whatever happens it doesn't need to be timed as it will do it at the end of a day.

I probably wouldn't do that either... could possibly build it in to the power-down script, but you don't want to hold the server up.  Might be better (and easier) to have it run in the background when you bring the server online... that's easy to do with an appropriate line of code in the go script.

 

You could try (but appreciate an expert weighing in on my amateur coding):

/usr/local/sbin/mover > /dev/null 2>&1

Ok, I tried that, I don't like it.

Thought you might not

 

Maybe we can try a different tack.

 

Is there a way of changing/running the script on sleep/array shutdown?

 

That way whatever happens it doesn't need to be timed as it will do it at the end of a day.

I probably wouldn't do that either... could possibly build it in to the power-down script, but you don't want to hold the server up.  Might be better (and easier) to have it run in the background when you bring the server online... that's easy to do with an appropriate line of code in the go script.

 

You could try (but appreciate an expert weighing in on my amateur coding):

/usr/local/sbin/mover > /dev/null 2>&1

 

Not bothered about it holding the machine up, it's the perfect time for the thing to do it anyway. Nothing will be writing/reading it and therefore the chance of something going wrong because it's being used is reduced greatly.

 

 

Not bothered about it holding the machine up, it's the perfect time for the thing to do it anyway. Nothing will be writing/reading it and therefore the chance of something going wrong because it's being used is reduced greatly.

Just be sure to consider the rare occasions that you might not be able to give the machine an extra 10 minutes to power down. I don't know how you would do it, but maybe consider figuring out a way to bypass it if necessary. I'd rather leave stuff on the cache drive until the next clean boot than risk corrupting my array because I couldn't shut it down without committing time to actively move data around. How good is your UPS?

Ok, I tried that, I don't like it.

Thought you might not

 

Maybe we can try a different tack.

 

Is there a way of changing/running the script on sleep/array shutdown?

 

That way whatever happens it doesn't need to be timed as it will do it at the end of a day.

I probably wouldn't do that either... could possibly build it in to the power-down script, but you don't want to hold the server up.  Might be better (and easier) to have it run in the background when you bring the server online... that's easy to do with an appropriate line of code in the go script.

 

You could try (but appreciate an expert weighing in on my amateur coding):

/usr/local/sbin/mover > /dev/null 2>&1

 

Not bothered about it holding the machine up, it's the perfect time for the thing to do it anyway. Nothing will be writing/reading it and therefore the chance of something going wrong because it's being used is reduced greatly.

 

 

If you do put this in your "go" script you'll also want to make sure the array is "completely" online before invoking "mover"

 

The mover script will not run if the cache drive is not present.  You need to wait for it to be online.

The move script will move files to /mnt/user

This is perfectly fine if the target folder exists on a DISK, but really bad if the target folder is created in memory if the physical disk is still in the process of being mounted.

The copy will seem to work, but the mount of the actual physical disk will probably fail, and when you power down, the in-memory copy will be gone.  Oops...

I've seen syslogs where it took over 15 minutes for a disk to be mounted after a non-clean shutdown.  The mover should be delayed at least that long unless you actively check for the array to be fully online and all disks mounted.

 

Joe L.

Not bothered about it holding the machine up, it's the perfect time for the thing to do it anyway. Nothing will be writing/reading it and therefore the chance of something going wrong because it's being used is reduced greatly.

Just be sure to consider the rare occasions that you might not be able to give the machine an extra 10 minutes to power down. I don't know how you would do it, but maybe consider figuring out a way to bypass it if necessary. I'd rather leave stuff on the cache drive until the next clean boot than risk corrupting my array because I couldn't shut it down without committing time to actively move data around. How good is your UPS?

 

That was my thought exactly... also, if the high-temperature warning goes off and the machine starts a rapid power-down, I wouldn't want the my drive cooking away for 10 minutes while the cache drive empties off! 

 

Provided you're not writing to the array when the mover script is running, I haven't noticed it take up much in the way of system resources or performance.  Why not just cron it to run at a fixed time each day (say 1pm), when you're having lunch and not using the array?  Perhaps I don't understand your usage pattern and this isn't an option.

I don't follow the usage pattern either. My personal opinion is that if you need immediate protection then either don't write to the cache and live with the slower write speeds or use something besides unRAID - like a small RAID1 or RAID6 array so you get both the protection and fast write speeds. But then, I set my mover to only run once a week.

 

You could install a cheap 2-port card and set it up in RAID1 and then mount and share it outside of the unRAID array. It might even be possible to do this for the cache disk so you get instant protection and then can run the mover once a day or once a week to archive the data. I think someone here is doing RAID0 for their parity and this would be simiar.

 

Peter

 

http://www.openjs.com/scripts/jslibrary/demos/crontab.php