I checked on my server this morning and noticed my disk1 has been taken offline and 965 errors are reported via the web console.

 

I've attached my syslog. I tried to take the smart data from the drive but it looks like the library for that isn't included in 4.4.2. I saw the notes in the wiki and tried to download the package but it wouldn't allow me to do so.

 

Anyways, I'm guessing that the drive had trouble waking up when my media center tried to access it and that's the reason for the errors and why it was taken offline. I've had this problem once before in the past.

 

What steps should I take for testing from here? I still have the server running just in case I need to grab some data from it.

I've had problems with this drive before so I decided to replace it (upgrading from 750 gig to 1TB).

 

I shut down the server, swapped out disks, and started the server. Disk1 still shows as not installed.

 

I stopped the array and assigned my new disk to the disk1 slot. I went back to the main page to start the array but it still shows as red and "Not Installed" as the serial number for the disk. There is no blue dot and it won't allow me to upgrade like it did in the past.

 

Obviously unRAID can see my new disk because it allows me to select it under the devices tab... so why isn't it letting me use it to replace my old failed disk?

If you are able to go to the devices page and assign a disk to a slot, it should absolutely show up on the main page as installed.  I think you need to take some screenshots to demonstrate this.

 

In general if you start getting disk errors from a disk, one of two things is happening ...

 

1 - The disk is failing.  You should see remapped sectors and other signs of failure on a smart report.

 

2 - The data or power connection to the drive is bad or loose (bad or marginal connections inside backplanes and docks could also cause these symptoims).  You should see few if any remapped sectors but lots of ata errors (i.e., logged errors) indicating unknown commands and sector locations in the smart report.

 

If you have a disk failing, you need to replace it as you are doing.

 

But if you have a cabling problem, replacing the disk is not only unnecesssary but potentially harmful.  Whatever the cabling issue it will likely persist with the new drive, and result in a bad rebuild.

 

Post a smart report of the suspect drive (if you can) and take some screen shots showing what you're seeing via the Web GUI.

Yea... after I posted that I decided to try swapping out the cable. Such a pain though because I had everything cable tied and tightly packed in my case. Took me 20 minutes just to get the cable out that was connected to disk1.

 

The good news is, once I swapped out the cable I was able to add my old 750 gig drive back to the array. It's rebuilding the data on the drive though (since I tried to already add the 1TB drive), so I'll need to wait for the to finish. But so far it's looking like the cable was faulty. Crazy how a non moving part like a cable can just one day go bad. Everything was so tightly packed in my case and tied together that the cable hasn't moved since I built the server.

 

Hopefully that was the problem and it's not something else. It very well could be the backplane and after fudging around with the case I moved something back into position in that slot. If I get this same error again on disk1 then I may have to RMA my backplane.

 

But if you have a cabling problem, replacing the disk is not only unnecesssary but potentially harmful.  Whatever the cabling issue it will likely persist with the new drive, and result in a bad rebuild.

 

 

I think I should be safe after the rebuild right now. If this cable has been bad for a while with marginal connections then some of the data on disk1 may have been corrupt. However, since it's rebuilding the data on disk1 right now it should rebuild all the data correctly so nothing is corrupt (I hope anyways).

Except that you had 965 errors.  Each one of those errors would have caused PARITY to be updated, and will be reflected in your rebuild.  If these are each the result of garbled data in a flakey cable, than parity has been scrambled 965 times.

 

There is a procedure called "trust parity" that would have let you put the disk back into the array withouth rebuilding parity or rebuilding the data disk.

 

I might have suggested doing the rebuild onto the NEW disk, and keeping the old one as is.  If you found that you had corruption on the new disk, the old disk might still have the data in an uncorrupted form.

 

Good luck with your rebuild!

 

* * * * *

 

Yes, it is surprising that cables go bad as they do.  You would think - hey, it just a wire.  I am far from an expert as to the why's, but can say that cabling problems are the #1 problem here.

But if disk1 had a flaky cable and I wrote to it, then the data would be garbled on disk1 but not on parity correct?

 

If I send a file to disk1 unRAID writes the data to both parity and disk1. Even if disk1 is writing incorrect data due to the bad cable, parity should be correct. Therefor, when rebuilding disk1 with a new cable it should write to the drive correctly (like it should have in the first place). Now, this wouldn't be true if I had rebuilt parity anytime lately, since that would have replaced the good data on parity with the bad data from dsik1.

 

But you make some good points. I should have added my new disk and left my old disk alone. That way if I did have a problem with the data written to the new disk I would still have the data on my old disk. I'll have to remember that for the future when a drive fails and I run into new issues .

 

Edit: The errors I had reported were read errors... therefor parity wouldn't have been touched and should still contain the correct data.

But if disk1 had a flaky cable and I wrote to it, then the data would be garbled on disk1 but not on parity correct?

 

If I send a file to disk1 unRAID writes the data to both parity and disk1. Even if disk1 is writing incorrect data due to the bad cable, parity should be correct. Therefor, when rebuilding disk1 with a new cable it should write to the drive correctly (like it should have in the first place). Now, this wouldn't be true if I had rebuilt parity anytime lately, since that would have replaced the good data on parity with the bad data from dsik1.

 

But you make some good points. I should have added my new disk and left my old disk alone. That way if I did have a problem with the data written to the new disk I would still have the data on my old disk. I'll have to remember that for the future when a drive fails and I run into new issues .

 

Edit: The errors I had reported were read errors... therefor parity wouldn't have been touched and should still contain the correct data.

 

I understand your logic.  If you have a read error on a disk, unRAID would likely try to reconstruct the data using parity and the other data disks and try and write that data back to the offending data disk.  This would force a sector remap if the disk got the read error due to a bad sector, but in this scenario it would just try and rewrite the sector.  No harm.

 

Thinking out loud here ... if unRAID did a read and got back a garbled response FROM the drive due to a bad cable, unRAID would not realize it got back a garbled response.  unRAID does not verify each read against parity.  So these would not trigger read errors nor cause parity to get updated.  No harm.

 

All of this is good news for you.  Your rebuild will likely be just fine.

 

If you were running a parity check, it is possible that a garbled read could corrupt parity.

 

Likely your 965 errors were on new data that you recently copied to the array.  Hopefully you have this backed up.  Don't dlete the most recent files copied to the array!

 

Good luck!

That's the thing though... I haven't written to that disk in probably 4-5 months now. I filled it up till it had 20GB's left and didn't want to add any more data after that point. They must be read errors... which is good for me

 

The syslog shows the disk started to error on the 8th. I remember exactly what happened to cause those errors. I had sat down to watch an old movie but mediacenter wouldn't start it. I knew the movie was on disk1 but I just thought media center was having issues with that specific DVD. But now I know that the disk started giving errors once I tried to watch a movie on it and that's why I couldn't watch the DVD.

 

Makes me feel better though knowing it was a problem with my unRAID server. I was planning on trouble shooting that vista mediacenter pc over the weekend (which is never fun).