Disk being seen as new when it isn't

[DigitalDivide]

I noticed one of my disks showing 144 errors.  So I shut down and rechecked all the cabling to make sure nothing was loose.  I also moved the SATA cable from one port on the promise controller to another.  WHen I booted up the server, the disk (disk 4) was missing. I went to Devices and set it back.  Now however it's been seen as a new disk and wants to rebuild the parity.  How can I set the disk back so it's not seen as new so I can start up the array and run a parity check?  I'd like to run a parity check and see if the errors go away.

[kenoka]

I'd try moving it back to its original port. I suspect that there's an issue with the drive though. Did you happen to capture the syslog with the 144 errors?

[DigitalDivide]

no I didn't.  I think I should be able to start up the arrary without moving the drive back.  I can't remember if it's initconfig though or something else.

[Joe L.]

no I didn't.  I think I should be able to start up the arrary without moving the drive back.  I can't remember if it's initconfig though or something else.

You can leave the disk where it is.

 

Stop the array

Log in as "root" via telnet, or on the system console.

Type:

initconfig

Respond with Yes

(exactly three letters, a capital "Y" and lower case "es")

"y","yes","yeah","ok","yup","YES", and nodding your head up and down are not equivalent and will be considered no.

When you use the initconfig command parity will immediately be invalidated as parity was base on the old disk configuration.

 

Refresh the management page, all the indicators should be "[glow=blue,2,300]BLUE[/glow]"

Then start the array.  It will immediately start a new full parity calculation.

[jimwhite]

Isn't that what the maligned Restore button is for? 

 

[Joe L.]

Isn't that what the maligned Restore button is for?   

 

The "restore" button was removed and replaced by the exactly equivalent "initconfig" command in later releases of unRAID.

 

Too many users pressed the poorly labeled "restore" button when they had a failed drive, thinking it would restore their data.  Instead, it invalidated parity, set a new disk configuration WITHOUT the failed drive, or its data,  and caused them to lose their data.

 

[DigitalDivide]

Thanks Jo, that's what I was thinking of.  Did a parity check and found 140 errors.  I guess I'll be replacing the drive.

[lionelhutz]

Maybe I'm not understanding your question, but if you did an initconfig with a bad data drive then you have just screwed yourself. That will have destroyed the once correct parity data that could have been used to rebuild the disk.

 

You could have used the trust my parity procedure and done a parity check only. I would have recommended either using unRAID or the command line to do a parity check with no correct as opposed to using the web interface button which is actually a check and correct parity. When a disk is acting up you most definately want to verify only and not alter the parity data.

 

Was the disk red-balled? Sounds to me like the array was running and the disk was dropped out and then it was treated like a new disk when you re-assigned it. The array has to be running without the disk assigned and then it gets treated like a new disk when you actually do assign it. You can change ports and re-assign a disk to the same slot again without having that problem as long as the disk is green and working in the array.

 

Peter

 

[Joe L.]

You could have used the trust my parity procedure and done a parity check only. I would have recommended either using unRAID or the command line to do a parity check with no correct as opposed to using the web interface button which is actually a check and correct parity. When a disk is acting up you most definately want to verify only and not alter the parity data.

You should NEVER NEVER NEVER use the "trust my parity" procedure if you have a disk that is acting up.  There are very limited times when it is helpful.  It is ONLY good if all the disks are working, and ALL (and only) the disks last used to calculate parity are currently assigned in the array.  Once he swapped disks it could not be used.

 

Joe L.

[lionelhutz]

You also NEVER NEVER NEVER EVER use an initconfig when you have a bad data disk.

You also NEVER NEVER NEVER EVER use an initconfig when you have installed a replacement data disk.

 

I though about this more and you only had one correct path. Using the trust my parity command will start a parity check that could change the parity drive and not allow you to fully recover disk4. Even if you cancel it right away some damage could be done. So, using the trust my array is not the way to fix your problem.

 

You should have just allowed the rebuild of disk 4. Then, you would replace disk4 if the rebuild failed.

 

Think of it this way. Assume your parity was built when all the disks were working correctly. So, unRAID can fully rebuild disk4 using the parity disk and other data disks. Now, you have read errors on disk4, meaning some data on disk4 is now corrupted. If you can' read a block on disk4 then that data is lost from disk4 and is only now stored via the parity disk. So, you wanted to rebuild disk4 and put the correct data back on it, not do a parity check and definately not do anything that could potentially update the parity with corrupt data from disk4.

 

I'd still like to know if the disk was red-balled or not.

 

Peter

 

[DigitalDivide]

To be honest, I noticed that my disk 4 was red and showed errors.  I shut down and reseated the cables and brought the array back online.  That's when the disk was seen as being new.  After I did the initiconfig and parity check, it came back again with about 200 errors or so.   The disk had been showing errors previously but I simply couldn't afford a new disk at the time.  I bought a new disk yesterday and preclearing it at the moment.  Once done, I'm just going to rebuild disk 4.  At this point I don't think I have any other choice.

 

Also I should add that my array had done a parity check previous with errors on disk 4, prior to me doing it this week while disk 4 was showing errors.  The power in my condo when out last week while I was at work and when it came back on started a parity check.

[lionelhutz]

OK , you probably already had data corruption.

 

One thing I didn't yet note (waiting for that red ball answer) is that unRAID will simulate the disk when it is red balled. So, any writes you did to disk4 while it was red balled did not get written to the disk4 hard disk but rather just reflected in the parity. So, an initconfig also erases the knowledge of these writes and you lose them.

 

Maybe you didn't write to the disk and it sounds like you're not too concerned with data loss. But still, you probably caused more data to be lost compared to attempting a rebuild.

 

Peter

 

[DigitalDivide]

From above "I noticed that my disk 4 was red and showed errors", so yes it was red balled.  On that specific drive I have a combo of music, movies, and pictures. For the most part I'm only really concerned about my raw pic files.  I guess I'll find out my loss once I do a rebuild and test.

[lionelhutz]

I guess I wasn't very clear. I didn't mean I was still waiting for the answer. I meant that I didn't post about data not making it to the disk until I got the answer you provided in the post I responded to. I caught that answer and already know the disk was red balled. Sorry about the confusion.

 

I hope your pictures come through unscathed.

 

Peter