I just happened to look at the console (unMenu) and my disk9 shows DISK_DSBL in Red type.  On the standard unRAID console all disks are green except disk9 which is red.  In the Command Area of the Main page there is an orange dot next to Started.  I saved a syslog (attached) and shutdown the server.  Restarted and same thing.

 

I'm getting worried -- any suggestions?

 

Thanks

Basically, you have a disk that has failed and unRAID has disabled it.

 

Before you replace it, you should power down and check the cable to that drive.   

 

If by chance it was loose, you can get unRAID to re-try that drive by going through these steps.

 

Stop the array

Un-assign the defective drive

go back to the main management page and reboot the server

When it comes back up go to the devices page and attempt to re-assign the drive to the slot.

 

If it comes back on-line, it was just the cable.  If not, time to purchase a replacement drive and install it.

 

Until you replace the drive you are at risk of loss of data if another drive were to fail.  Do not delay in replacing the failed drive.

 

Whatever you do, DO NOT press the "Restore" button.  It does not restore data, but it instead removes your super.dat file and forces a complete parity re-calc and immediate loss of all data on the failed drive.

 

When you replace the drive, you will need to assign it to the failed slot on the devices page, then you will need to check the "I'm sure checkbox under the "Start" button and then press the "Start" button to rebuild the data onto the replacement drive.

 

Joe L.

Thanks for the reply.  I can replace the failed drive (500GB) with a bigger drive (1TB).  Is that correct?

 

 

Thanks for the reply.  I can replace the failed drive (500GB) with a bigger drive (1TB).  Is that correct?

 

Yes and unRAID will automagically expand the filesystem to the drive's physical limit.

Only if the parity drive is also a 1tb or larger .

 

Thanks for the reply.  I can replace the failed drive (500GB) with a bigger drive (1TB).  Is that correct?

 

Yes and unRAID will automagically expand the filesystem to the drive's physical limit.

Only if the parity drive is also a 1tb or larger .

 

Thanks for the reply.  I can replace the failed drive (500GB) with a bigger drive (1TB).  Is that correct?

 

Yes and unRAID will automagically expand the filesystem to the drive's physical limit.

Forgot to elaborate that point. I'm so used to it I forget to mention it all the time.

 

Sometimes I think there should be a manual override option to allow a data drive to be limited to the parity drive's size.

This way in a pinch you could replace a failed drive without the cost of a parity upgrade at that particular moment.

If the replacement disk is larger than the parity disk, assign it as parity and assign the old parity disk as the failed data disk.

 

Unraid will first copy parity from the old parity disk (now in the data slot) and then it will rebuild the data disk from parity and the remaining data disks.  It will take a while longer as the data is copied from old parity disk to new can take several hours or more, especially of the parity disk is a 1T disk, but by using this procedure, the new disk can be bigger than the existing parity disk.

 

Joe L.

Can this parity replacement procedure occur while a data disk is in a failed state?

Can this parity replacement procedure occur while a data disk is in a failed state?

 

yes.  Although a more accurate term would be that it is a parity-swap procedure.

 

Joe L.

Now THERE's something good to know .

 

Well thanks everybody -- I'm back up and running with an extra 500GB as well.  I replaced the failed 500GB with an new 1TB.  It was pretty scary because when I was finished rebuilding the failed drive, only one of my shares was visible.  I thought for a minute that all data was lost.  Then I remembered that the user shares are populated at startup or boot.  I went to MC and saw my data on the disks, so I saved a syslog just in case, rebooted the server, and everything is back as it was.

 

Thanks Tom for a great product.  Thanks equally as much to the members of this community who help and serve as a valuable resource to this user group. 

By the way -- Here is the last SMART_RESULTS from my failed drive.  This report runs every time the system boots.  Could I have anticipated this failure from examining these reports?

 

I had been noticing this disk in particular would be colored yellow in unMENU as its temperatures elevated to around 40 - 41 degrees in the last week or so.  I just thought it was no big deal and that it was warm in the room.  I think this was the first clue that trouble was coming.

Could I have anticipated this failure from examining these reports?

 

Not that I can see. Even SMART itself could not predict the impending failure at the point this smart data was dumped.

However, I've have seen a short or long test change the results of what seems to be a good report card.

I did not comment on your syslog, because Joe was dead on with his comment to power off and check the cable.  The error sequence you had (exception Emask, BadCRC) I believe is usually associated with a cable problem, or other communications issue between the drive and the controller.  It does not surprise me that you have a clean SMART report, as there was probably nothing wrong with that drive.  For some reason, probably bad or loose cable, it lost communications with the drive, and was unable to regain communications, so it disabled it.

Oh -- well that's good news -- I guess.  I saved the drive so I can do some offline tests with it later.  After reading the suggestion, I did shutdown the server, open it up, double check all of the cables and ensured the SATA cards were seated tightly.  I then started the server but the same disk was in the same disabled state.  That's why I went with the suggestion of replacing the drive.  Everything seems to work now but is there something I should be checking to ensure that everything is working properly?  The only red lines in my syslog tab in unMENU are these --

Oct 10 12:34:24 Tower kernel: ACPI Error (dswstate-0226): No result objects! State=f7f79000 [20070126]
Oct 10 12:34:24 Tower kernel: ACPI Exception (dsutils-0642): AE_AML_NO_RETURN_VALUE, Missing or null operand [20070126]
Oct 10 12:34:24 Tower kernel: ACPI Exception (dsutils-0735): AE_AML_NO_RETURN_VALUE, While creating Arg 1 [20070126]
Oct 10 12:34:24 Tower kernel: ACPI Error (psparse-0537): Method parse/execution failed [\_TZ_.THRM._TMP] (Node f7c16078), AE_AML_NO_RETURN_VALUE

Is this something I should be concerned with?

Thanks as always for the help.

You are using an early version of the Unmenu syslog viewer.  There's been considerable improvement in more correctly specifying issues, and their degree.  Those ACPI problems should be considered minor issues, worthy of note, but not of major concern.  And they have been fixed in the Linux kernel included with the unRAID v4.4 betas.

Okay -- thanks very much for the info.  I had been keeping current on unMENU (I thought).  I think I got confused because I downloaded a version from the forum thread as well as one from the repository.  Or I messed up trying to keep my own pages intact while upgrading to a new version.  Or I just missed a key post.  Really, it could have been anything.  Sorry about that -- I will upgrade shortly.

You are using an early version of the Unmenu syslog viewer.  There's been considerable improvement

 

Okay -- thanks very much for the info.  I had been keeping current on unMENU (I thought).  I think I got confused because I downloaded a version from the forum thread as well as one from the repository.  Or I messed up trying to keep my own pages intact while upgrading to a new version.  Or I just missed a key post.  Really, it could have been anything.  Sorry about that -- I will upgrade shortly.

 

This is where something like google code could help a great deal.

The current page/repository could be a jump point to the google code page.

 

http://code.google.com/

 

I plan to put my powerdown and powercontrol scripts there.