Joe,

 

I decided to run the latest beta of unRAID.  I started with 2 disks, and upgraded to the pro license.  After that I added 4 drives more plus the parity disk at the same time.  When I assigned all of these new drives the system obviously needed to format and do a parity check.  I noticed this morning that all of the hard drives had completed parity check and were spun down, however unRAID web GUI continued to report that the disks were formatting.  The system would not respond to a reboot command issued in the terminal as well and I had to do manually cycle the power to the system. 

 

The only possible glitch in the system is that I hot swapped a 120gb SATA drive that didn't like AHCI (unbeknown to me) during the process.  I figure the easy answer is that my non-AHCI SATA drive caused the issue.  However, that may not fully explain the fact that the drives continued and finished the format / parity check without issue. On this point I'm not sure. I should have added the parity drive last, but got carried away. 

 

Do you think there could be an issue when formatting multiple disks and adding the parity drive at the same time?

Joe,

 

I decided to run the latest beta of unRAID.  I started with 2 disks, and upgraded to the pro license.  After that I added 4 drives more plus the parity disk at the same time.  When I assigned all of these new drives the system obviously needed to format and do a parity check.  I noticed this morning that all of the hard drives had completed parity check and were spun down, however unRAID web GUI continued to report that the disks were formatting.  The system would not respond to a reboot command issued in the terminal as well and I had to do manually cycle the power to the system. 

 

The only possible glitch in the system is that I hot swapped a 120gb SATA drive that didn't like AHCI (unbeknown to me) during the process.  I figure the easy answer is that my non-AHCI SATA drive caused the issue.  However, that may not fully explain the fact that the drives continued and finished the format / parity check without issue. On this point I'm not sure. I should have added the parity drive last, but got carried away. 

 

Do you think there could be an issue when formatting multiple disks and adding the parity drive at the same time?

I've not heard of such a bug, but most people do one thing at a time.  Adding the parity drive last just allows a quicker initial load/migration of data to the array, but at the expense of not having any parity protection until parity is calculated. 

 

However...If you could not get a response from the terminal to reboot, then odds are you might have glitched the MB/power supply when hot-swapping in the drive.

 

I would not trust that the formatting completed... I would run a riserfsck on each of the "data" disks to be sure.  I'd also do a full parity check.

 

Since this is a new array,  I'd triple check that the memory voltage, timing, and clock speed are all set for your specific RAM.  Many motherboards set it automatically, and many get it wrong.    It wouldn't hurt to run a memory-test through a few cycles.  More than one server has crashed because the memory was set up incorrectly in the BIOS.

 

I'd also post a syslog when you get a chance... just to ensure there was no other reason you crashed.

 

Joe L.

Do you think there could be an issue when formatting multiple disks and adding the parity drive at the same time?

 

Yes, there could be issues with doing all this work at the same time.

In theory you should not have had this occur. If you are hot swapping a drive while all this work is active, this could cause the controller or driver to timeout somewhere.

 

I have read of others having issue with multiple simultaneous formatting and parity check.

If your power supply is not up to snuff, this will reveal it.

If there are any IRQ, ACPI or bus issues this will reveal it.

 

There is mention that the machine was unresponsive to a reboot request.

Did the machine lock up, or where you able to at least login or navigate around the browser interface.

 

 

Joe & WeeboTech,

 

I started another parity check as I left the house and will have to run RiserFSCK when I get home.

 

I'm 99.9% certain that it is not related to hardware settings (outside of the 120gb HD).  The power supply is really overkill for what I am currently running and is plugged into a UPS.  The memory I've got in the system is rated 1066Mhz 5-5-5-18 at 1.6v (the 0.1% is b/c this Gigabyte board will not let me adjust the memory voltage below JEDEC specs).  Also, I've spent the last 3 or 4 days testing the timings and other settings on the system to ensure stability with the 2 test disks before adding the others.

 

I was able to login as root in the terminal and also navigate in the web interface.  The system seemed fully operational other than the fact that the HDD status would not update beyond formatting on the web GUI. Please note that the 120GB drive was added to the SATA bus while the format/parity check on the main drives was in process; I never assigned the 120gb drive to a disk slot in unRAID.  During this time, I did not notice any loss of functionality. I was able to monitor hard drive temps, r/w progress of the format/parity check and watch my smaller drives actually power down after the parity check was completed on them.  In all, I probably watched the system for a good 3-4 hours with the 120GB disk connected to the SATA controller without any noticeable issues.

 

Since I discovered this issue right before work I did not have time to look up the console commands to unmount the array via the command line and do a clean power down.  The reboot command locked the system and I believe this could have occurred due to the SATA controller not being able to communicate with the 120GB drive.  Once I cycled the power on the system, the system locked up at boot time trying to update DMI pool with the old 120gb hard drive in the pool.  After I removed the 120gb drive and rebooted, everything was fine.  Thus, I recognize this hard drive could very well have caused the issue; In fact, ordinarily I'd completely chalk it up to the one particular HDD, since it is a problem child.  However, I was expecting a hard lock of the system or the storage subsystem upon plugging the drive in if it were the sole cause.  With my ability to use both interfaces and the fact that all of the stats indicated the parity check ran successfully, I wanted to at least bring it to your attention in case there is an underlying issue in the setup/format process not associated with the problematic hard drive.

Joe & WeeboTech,

 

I started another parity check as I left the house and will have to run RiserFSCK when I get home.

 

I'm 99.9% certain that it is not related to hardware settings (outside of the 120gb HD).  The power supply is really overkill for what I am currently running and is plugged into a UPS.  The memory I've got in the system is rated 1066Mhz 5-5-5-18 at 1.6v (the 0.1% is b/c this Gigabyte board will not let me adjust the memory voltage below JEDEC specs).  Also, I've spent the last 3 or 4 days testing the timings and other settings on the system to ensure stability with the 2 test disks before adding the others.

 

I was able to login as root in the terminal and also navigate in the web interface.  The system seemed fully operational other than the fact that the HDD status would not update beyond formatting on the web GUI. Please note that the 120GB drive was added to the SATA bus while the format on the main drives was in process; I never assigned the 120gb drive to a disk slot in unRAID.  During this time, I did not notice any loss of functionality. I was able to monitor hard drive temps, r/w progress of the format/parity check and watch my smaller drives actually power down after the parity check was completed on them.  In all, I probably watched the system for a good 3-4 hours with the 120GB disk connected to the SATA controller without any noticeable issues.

 

Since I discovered this issue right before work I did not have time to look up the console commands to unmount the array via the command line and do a clean power down.  The reboot command locked the system and I believe this could have occurred due to the SATA controller not being able to communicate with the 120GB drive.  Once I cycled the power on the system, the system locked up at boot time trying to update DMI pool with the old 120gb hard drive in the pool.  After I removed the 120gb drive and rebooted, everything was fine.  Thus, I recognize this hard drive could very well have caused the issue; In fact, ordinarily I'd completely chalk it up to the one particular HDD, since it is a problem child.  However, I was expecting a hard lock of the system or the storage subsystem upon plugging the drive in if it were the sole cause.  With my ability to use both interfaces and the fact that all of the stats indicated the parity check ran successfully, I wanted to at least bring it to your attention in case there is an underlying issue in the setup/format process not associated with the problematic hard drive.

Your description does not equal that of a hard crash.  It could easily be a disk controller that got confused somehow, or, as you said, the specific drive locking up the channel.

 

A syslog will go a long way to seeing what is actually happening.  If you ever have a similar situation, capture a copy of the syslog before you reboot. (instructions in the Wiki under troubleshooting)

 

Un-mounting the array by hand is a bit tricky, as you must first stop samba, then un-mount all the physical drives, then stop the array.

The web-management page "Stop" button does this sequence for you.

 

You can download and install the "powerdown" add-on, and it can perform all the required steps too.  The unMENU alternative interface also provides a clean powerdown... as will the unRAID-Web alternative interface. (both of those are a series of web-pages developed by the user-community... unMENU is a written in "awk" while unRAID-Web uses lighttpd as its web-server.  Both serve pages on alternate ports, so the normal supplied web-management page is always available and in fact necessary to start the array.

 

Joe L.

You can download and install the "powerdown" add-on, and it can perform all the required steps too.  The unMENU alternative interface also provides a clean powerdown... as will the unRAID-Web alternative interface. (both of those are a series of web-pages developed by the user-community... unMENU is a written in "awk" while unRAID-Web uses lighttpd as its web-server.  Both serve pages on alternate ports, so the normal supplied web-management page is always available and in fact necessary to start the array.

 

The powerdown tool,  or some derivative too, that hooks into /etc/rc.d/rc.local_shutdown will try to cleanly unmount the array and stop it no matter what method you use.

 

I.E. Your power button, CTRL-ALT-DEL, reboot command or one of the interface programs.

 

The power button requires ACPI to work correctly.

CTRL-ALT-DEL power off requires installing power down with some options.

 

The others will just call the script in line with normal shutdown/reboot procedures.

(it also saves a copy of your syslog onto the flash).

 

http://code.google.com/p/unraid-powercontrol/downloads/list

 

 

Figured since I already had this thread open I'd use it to get some further input.  I assigned my cache drive to the array but writing to it was extremely painful, at all times it was no better than having a 100Mbps connection maxed to the array.  So after troubleshooting the network connections etc, I finally pulled the cache drive and my write speeds directly to the array are somewhere between 14-40MBps.  The cache drive was an old Maxtor 120gb SATA I drive I had sitting in one of my old systems... (it is also the problem drive from above).  Do you guys think I could have just picked a bad drive to use as a cache drive?