Hi guys,

 

I've been running 5.0rc4 for awhile without any disk issues. Upgraded to rc11 yesterday and on the first reboot got a red ball on one of my disks that had an error count of 120. I'm reasonably confident that there are no issues with the disk so I tried to re-enable it following instructions I found in the FAQ http://lime-technology.com/wiki/index.php/FAQ#How_do_I_re-enable_a_failed_disk.3F

 

Unfortunately when I start the array for the final time the disk goes back to a red ball and I don't get the option of running a parity check. Is there anything I can do to re-enable the disk and run a parity check?

 

Thanks.

The drive is removed from service when a "write" to it fails.  Unless you did something to fix the cause of the failure, it will fail in exactly the same way when you next write to it.

 

odds are the disk is defective OR the power OR data cable to it is defective OR the power OR data cable to it is loose OR the disk controller is it attached to is defective, or the drive tray it is in is loose and not making a good connection to the backplane, or the backplane is defective or the power supply is unable to supply the total load of the disks and that one disk is most sensitive to the poor voltage regulation..

 

You can

  A. see if the disk is detected by the BIOS when you power cycle the server

  B. can you get any output from

    hdparm -i /dev/sdX

    or

    smartcl -a /dev/sdX

    (If this only produces a few lines stating it cannot read the superblock, then the disk cannot communicate with the MB, for one of the above reasons)

Could it also be that the ReiserFS is corrupt? Maybe a reiserfsck will tell?

Could it also be that the ReiserFS is corrupt? Maybe a reiserfsck will tell?

no, as that would not make a subsequent "write" fail and take the disk out of service once more.

 

Now, the file system might be corrupted as a result of the failed write to the physical data disk, but should be perfectly correct on the emulated disk.  (in other words, the write to parity did not fail)

 

for that reason, forcing the disk back into service by "trusting" it is really an invitation for file-system corruption.  you know a write to the physical disk failed, and you are betting that whatever was being written was not important to either a file or the file-system.  Honestly, the odds are not in your favor.

 

 

Thanks guys for the info, I ended up downgrading to my previous version of unraid and everything is working fine again.

 

If there are write errors on the disk why does none of the SMART tests show a problem?