Jump to content

Disk being seen as new when it isn't


Recommended Posts

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.

Link to comment

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.

Link to comment

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

 

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.

 

Link to comment

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

 

Link to comment

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.

Link to comment

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

 

Link to comment

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.

Link to comment

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

 

Link to comment

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

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...