Hi,

 

I was opening my HP Microserver and before it had completely shutdown, like an idiot I bumped a cable and now have a red dot on my disk 4. How can I force the array to just use that disk as normal and that it has not failed?

 

Currently running: reiserfsck --check /dev/md4 but I think it should come back all good. What's the process from there?

 

 

Thanks!

Anyone?

Note that the reiserfsck is running against the md4 device which as the drive has been red-balled is a 'logical' device constructed from parity plus the other drives.  This can mean that the physical drive is slightly different.

 

I would expect the reiserfsck to complete without error.  If by any chance it does not you might want to check back here before proceeding.

 

With the reiserfsck completed without error, then assuming that you are happy the physical drive is OK, the process to recover from this is:

• Stop the array and set the 'red'balled drive as unsassigned.  You should now be warned that there is a missing drive and the array is unprotected.
  
• Start the array with the missing drive.  It should come up as normal with the drive still red-balled; disk4 marked as missing and a warning that the array is unprotected.  This step is needed to get unRAID to 'forget' the serial number of the red-balled drive.  It is also simulating a physical drive failure.
  
• Stop the array and assign disk4 back again.    This time you will be told that if you start the array disk4 will be rebuilt.
  
• Start the array and let the rebuild onto disk4 run to completion.  In fact the majority of the writes to disk4 will simply be overwriting sectors on the physical disk with the same data as the 'logical' disk has the same contents
  
• When the rebuild of the disk has completed run a non-correcting parity check to validate the rebuild.  Ideally this should finish without any errors being indicated, and if that is the case your array is up an running its normal protected mode.
  

If you get an error at any point I would strongly suggest you check back here before taking any other action.  Depending on the error the suggested recovery process is likely to differ slightly.

Sorry I got impatient  I managed to resolve this. I stopped the array, took a print screen of the drives positions, telnet and ran "initconfig" then "/root/mdcmd set invalidslot 99". After than I refreshed the page, reassigned all the drives to their correct slots, checked the box "Parity is already valid" and click start. Seems to have done the trick, all my data is still there...Running a parity check just to confirm all is good.

Sorry I got impatient  I managed to resolve this. I stopped the array, took a print screen of the drives positions, telnet and ran "initconfig" then "/root/mdcmd set invalidslot 99". After than I refreshed the page, reassigned all the drives to their correct slots, checked the box "Parity is already valid" and click start. Seems to have done the trick, all my data is still there...Running a parity check just to confirm all is good.

That approach will work - but if you wrote anything to the array after the disk red-balled this approach could lose that data.  This would be indicated by the fact that some corrections to parity needed doing during the parity check.

 

Note that with v5 onwards there is a 'new config' option on the Tools tab so no need to use an initconfig command via the command line.

Thanks, as long as majority of my data is still there I'm happy camper, serves me right for having no patience.

Parity just finished checking and it looks like I did lose some data:

Last checked on Sat Oct 11 23:18:51 2014 SAST, finding 155 errors.

Not sure what though...But it's all working some I'm happy

Parity just finished checking and it looks like I did lose some data:

Last checked on Sat Oct 11 23:18:51 2014 SAST, finding 155 errors.

Not sure what though...But it's all working some I'm happy

That is not very many, so it is likely to only be the last file written (if any).    A small number is virtually guaranteed with the approach you take as areas like the journal area on the disk were almost certainly different.