Well, I know that unRAID was developed for just this reason so I'm trying to not freak out.

 

I have a drive disabled and I truely believe that it is dead.  I came home today to an overheated server.  It was my bad as I keep my server in the garage and it hit well over 100f today.  Before I shut down there was already evidence that something bad happened to drive #5 (unable to query SMART data).  So, I wasn't surprised to see that after I moved the server to an air-conditioned space, let it cool down, and restarted that when it came back up drive #5 was disabled.

 

I'm running a long-SMART check on it now but I believe that I'm going to have to replace the drive and rebuild.  Could someone please point me in the direction of a procedure so that I do this correctly.  I'd sure hate to lose what I have on drive #5.

 

EDIT: I've attached a syslog that is from the first reboot mentioned above.

The procedure is the same for replacing a failed disk or upgrading a disk.

 

If your replacement disk is as big, or bigger than the failed drive AND the replacement disk is not bigger than the parity disk it is very easy.

 

All you need do is to stop the array, power down, replace the existing disk5 with a new one and then power up.

  If you use the same cable/disk controller port  for the new disk as the old you will not need to use the devices page to assign the new disk to the slot in the array on the devices page.  If you use a different hardware port you will need to assign the new disk to the failed disks' slot on the devices page.

 

Back on the main management page, unRAID will recognize that you replaced the disk and wait for you to check the box under "Start" and then press "Start" to rebuild your data onto the replacement disk.   

 

All you need to is press "Start" after checking the checkbox under it.

 

You will need to refresh your browser every once in a while to track the rebuild progress.

 

If the replacement disk is bigger than your parity drive, then put it in the parity slot and the old parity drive in the failed data slot (on the device assignment page) and then check the box under "Start" and then press "Start" to rebuild your data onto the replacement disk. In this parity swap process, the old parity drive is first copied to the new before being used to rebuild the data onto the old data parity drive now assigned as the replacement data drive.

 

Whatever you do, DO NOT PRESS the button labeled "Restore" as it does not restore data, but an initial config without parity calculations based on assigned-working drives.  It would cause you to lose all the data on a failed drive.

 

See here for screen shots:

http://lime-technology.com/wiki/index.php/FAQ#How_do_I_replace_a_hard_disk.3F

 

Joe L.

Thank you Joe. 

 

It looks to be a very simple procedure.  All my drives (7 data & 1 parity) are 1TB WD Green drives.  I just need to go and get another one and pop it in.

 

While the bad drive is still in the system I'm trying to find clues as to why it is 'disabled'.  Looking at the smart status report it isn't immediatly clear to me why this is the case.  I've attached a copy.

unRAID will only disable a drive if a "write" to it fails.

 

So, a "write" to drive5 failed.

 

unRAID will never automatically restore a failed drive.  The only way for it to recognize and re-try the drive is for you to

un-assign it,

reboot,

re-assign it.  It will be thought of as a new (replacement) drive for the failed drive.

The "Start" button will then rebuild the old contents of disk5 back onto disk5 by reading all the other data disks in combination with parity.

 

Your "smart" data looks pretty normal, it might be that the drive just overheated in your original failure. Or, it could be that a cable connector expanded in the heat and lost connection... no way to really know.

 

The only way to know what really happened is if you would have saved the syslog before you initially rebooted the server, after detecting the disabled drive.  Since you did not, you can only guess.  even if you had it, it would just show a write failure, and a disk error of some kind, but not the actual physical cause if it indeed was a loose cable or connector. 

 

Your smart report for your disk shows a "worst" temp of 107C.  That's pretty warm (224.6 degrees F), you might want to check the fans in your enclosure.

Joe L.

The attached SMART report was pulled for Disk 5 hours after relocating the server to an air conditioned space.  The current value shows as 118.  At a value of 118, the RAW_VALUE is 32.  I believe in this case a value of 118 from the temp sensor factors to a value in centegrade of 32c. 

 

If the drive went thermal and actually hit 225 degrees F, I think my server would have caught fire!!

 

If the current value is 118 I don't understand how 107 could be my worst value?  Maybe the value the temp sensor reads actually goes down as the temperature goes up.

 

From the sounds of it I could actually try to rebuild onto this drive.  But, I'd be afraid if it didn't work that I'd lose my chance to rebuild onto a new drive.  That being the case, I think I'll replace the drive with a fresh one.  Then I'll test this drive outside of the system and maybe use it as a cache drive if it still looks to be OK.

 

BTW: When I replace a drive using the procedure described (as opposed to adding a new drive) do I still need to run the pre-clear script on the drive first?

BTW: When I replace a drive using the procedure described (as opposed to adding a new drive) do I still need to run the pre-clear script on the drive first?

Completely up to you if you pre-clear or not when replacing a failed drive.  (weighing the risk of having your array unprotected during the additional time it takes to run.) 

 

All the pre-clear script will do, is let you know of any early failures on the new disk.  It will not save you any time in the rebuilding of the new drive once you put it in the array in place of the failed drive.

 

 

Joe L.

Thank you Joe for the good information.  I realize that all this info is available somewhere on the forum, but while I'm freaking out about a drive failure - searching a forum is not as comforting as a response from someone like you.

 

I thought I had read somewhere that a pre-clear wouldn't save any time when replaceing a drive.  Thanks for the clarification.

 

I have the new drive in right now rebuilding as I type this response.  I'm feeling pretty good about my prospect for success, and I'm feeling pretty good about unRAID right now.

 

I'm running Western Digital Data Lifeguard tests on the drive that "failed" right now too.  It already passed the short test, and the extended test is running right now.  If it passes I think I'll use it as a cache drive until I need more space in my array.

Thank you Joe for the good information.  I realize that all this info is available somewhere on the forum, but while I'm freaking out about a drive failure - searching a forum is not as comforting as a response from someone like you.

 

I thought I had read somewhere that a pre-clear wouldn't save any time when replaceing a drive.  Thanks for the clarification.

 

I have the new drive in right now rebuilding as I type this response.  I'm feeling pretty good about my prospect for success, and I'm feeling pretty good about unRAID right now.

 

I'm running Western Digital Data Lifeguard tests on the drive that "failed" right now too.  It already passed the short test, and the extended test is running right now.  If it passes I think I'll use it as a cache drive until I need more space in my array.

Odds are the drive will pass, but this is a perfect time to put it through a few cycles of the pre-clear script.  I recently posted a new version, so you might want to grab a new copy.  The internal "long" test you are running is just the internal SMART test.  The preclear script tests communications to and from the drive as well.  I think the internal test only does "reads" of the disks... I doubt if it tries to write.

 

Hopefully, by the time you read this, your disk will be rebuilt.

 

Joe L.

I guess I'm dense this morning. Where can I find the new pre-clear script Joe?

 

Thanks

I guess I'm dense this morning. Where can I find the new pre-clear script Joe?

 

Thanks

Same place it has always been.  At the bottom of the first post in the thread that describes it. http://lime-technology.com/forum/index.php?topic=2817.0

Thanks Joe. Like I said I was dense this morning. 

 

Thanks for the quick response.

Well, I ran the drive through 2 pre-clear cycles with no error.  I'm now running a 3rd with the -n option (don't know why it just looked like a good idea that wouldn't hurt.)  Now I'm beginning to become comfortable in the knowledge that there is nothing wrong with this drive and I think I'll redeploy it as a very large Cache drive until I need to use it to add more space in my protected array.

 

One more question though...  I was thinking about what Joe said about why & when unRAID will mark a disk as 'Disabled':

 

unRAID will only disable a drive if a "write" to it fails.

 

So, a "write" to drive5 failed.

 

Joe L.

 

Well, as it happens, this particular disk was completely full with .ISO files (99% full, 15GB free).  I haven't intentionally written to this disk for months, and there should have been no writes happening to this drive at the time that unRAID disabled it.  Could this mean that unRAID is writing to the disk for its purposes, or is there another reason (besides a failed write) that unRAID will disable a drive?

 

JT

I haven't intentionally written to this disk for months, and there should have been no writes happening to this drive at the time that unRAID disabled it.  Could this mean that unRAID is writing to the disk for its purposes, or is there another reason (besides a failed write) that unRAID will disable a drive?

 

JT

A disk is written to every time it is "mounted" to record the mount status and date/time.  These are house-keeping writes, not affiliated with your data files on its file-system.

 

When you re-located the server to a cooler spot, it is as likely as any that you caused the connection to the disabled disk to loosen, or perhaps it had not yet cooled to where the disk would respond when the "write" to it in the attempt to record the "mount" status/time would fail.    SATA cables don't have a very secure physical connection... It is easy to see how the overheat situation would expand the connection and result in an intermittent connection.

 

Joe L.