Hi,

 

I've looked around and didn't find an exact answer to my questions. I've rebooted my unraid server this morning and it started a parity-check. Based on the documentation, this will happens if the system was not shutdown cleanly. I've initiated a linux shutdown, assuming there is a script that would cleanly stop the array before. Is it the case? If so, which script is responsible for this so that I can figure why the parity-check was required?

 

I also notice that during the parity-check, I can access disk with \\tower\disk1 but I can't see the user share drives (stuff like \\tower\public). Is that a normal behavior?

 

With 2 TB drives, it is taking over 5-6 hours to do a parity-check so... I would like to avoid this as possible. Particularly if it is true that user share won't be accessible for that whole time.

 

Thank you.

 

ehfortin

I've looked around and didn't find an exact answer to my questions. I've rebooted my unraid server this morning and it started a parity-check. Based on the documentation, this will happens if the system was not shutdown cleanly. I've initiated a linux shutdown, assuming there is a script that would cleanly stop the array before. Is it the case? If so, which script is responsible for this so that I can figure why the parity-check was required?

 

The unix shutdown DOES NOT cleanly shutdown the array, hence your need for a parity check.

See http://lime-technology.com/forum/index.php?topic=6742.msg65596#msg65596 for a discussion on alternatives.

 

Hi,

 

I've looked around and didn't find an exact answer to my questions. I've rebooted my unraid server this morning and it started a parity-check. Based on the documentation, this will happens if the system was not shutdown cleanly. I've initiated a linux shutdown, assuming there is a script that would cleanly stop the array before. Is it the case?

You assumption was wrong.  The Linux shutdown will not cleanly stop the array.  As far as I know, there is no script to stop the array.  There is a command to power down, it is

powerdown and will attempt to stop the array.  It will NOT power down is a disk is busy, so it might work, but may not.  It is in /usr/local/sbin/powerdown.  It uses "wget" to "click" on the button on the user-interface.

 

There is a user-created add-on script, also named "powerdown" that will install as /sbin/powerdown that will kill processes and stop the array and then power down the server.  You might want to install it.  You'll then need to invoke it with the full path /sbin/powerdown , otherwise, you'll get the lime-tech command with the same name and not shut down if a disk is busy.

 

If so, which script is responsible for this so that I can figure why the parity-check was required?

As I said, you did not stop the server first and you caused a non-clean shutdown and therefore, you needed a parity check upon reboot.

I also notice that during the parity-check, I can access disk with \\tower\disk1 but I can't see the user share drives (stuff like \\tower\public). Is that a normal behavior?

All shares should be visible.

With 2 TB drives, it is taking over 5-6 hours to do a parity-check so... I would like to avoid this as possible. Particularly if it is true that user share won't be accessible for that whole time.

 

Thank you.

 

ehfortin

All shares should be visible, even during the parity check.  It is possible your non-clean shutdown caused some other issues.  Look in your system log for a journal being re-played upon re-start.  I know on my system if it has a non-clean shutdown it can take over 10 minutes upon re-start before the file-systems are all on-line.  That time is taken for re-mounting the file-systems and re-playing their transaction journal.

 

For it to only take 5 or 6 hours for a parity check  with 2TB drives involved indicates you have a very fast system indeed.  

6 hours =  21600 seconds

2000000 MB / 216000 =  92.6 MB/s.   (Faster than average)

This is also why there is a user community addon called 'PowerDown' - http://lime-technology.com/wiki/index.php?title=Powerdown_script

 

It hooks into rc.local_shutdown to provide clean shutdowns.

 Look in your system log for a journal being re-played upon re-start.  I know on my system if it has a non-clean shutdown it can take over 10 minutes upon re-start before the file-systems are all on-line.  That time is taken for re-mounting the file-systems and re-playing their transaction journal.

 

To add to the above this is compounded with the parity check going on as well which slows the above down even more.

 

When this has happened to me it has sometimes taken up to an hour before all disks, and finally the user share, are back online whilst the parity is being checked.

 

I've installed PowerDown and tried to call a shutdown guest from ESXi and it seems to work properly now. At least, I didn't had to do another parity-check yet. I saw lot of steps that were not showing when I did the shutdown previous to that so... I'm pretty confident that will fix the problem.

 

Thank you all for your response. It was fast and very informative.

 

 

ehfortin

I've installed PowerDown and tried to call a shutdown guest from ESXi and it seems to work properly now. At least, I didn't had to do another parity-check yet. I saw lot of steps that were not showing when I did the shutdown previous to that so... I'm pretty confident that will fix the problem.

 

Thank you all for your response. It was fast and very informative.

 

 

ehfortin

Don't forget you need to re-install PowerDown every time you reboot.  Otherwise, it does not exist.

I've installed Unraid on a full Slackware distro (13.1) so PowerDown won't disappear. That's the advantage of this setup as I can install any package/service I want without having to think at how to manage the reboot problem.

 

Thank you for the post anyway. It is a good tip for anybody that is using the standard Unraid installation.

 

ehfortin