Jump to content

Replaced 'faulty' disk - but still have an error


Recommended Posts

Hi, not sure what to do with this one...


My build is only a couple of weeks old, but one of the empty drives which unRAID started writing to came up with an error, saying disk was being emulated.

As it happens, I had another disk of the same size already pre-cleared, but hadn't added it to the array.


So I stopped the array, changed 'disk 4' from the current disk to the spare disk - so didn't physically move anything - and restarted the array

It went through the rebuild process which has just completed.


However, the same disk 'Disk 4' has again come up with an error - pretty much immediately after the rebuild finished.

Given it's a different physical disk - attached to a different bay - is there a step I've missed / another problem, or do I really have 2 dodgy disks in a row?



In case it's relevant, I'm still on the trial version of 6.3.3 - but understood that the trial version doesn't have a drive limit?


The drives in question are 4TB WD Greens


I've attached the diagnostics file

WD40EZRX-00SPEB0-WD-WCC4E0215810 - 4 TB (sdc) - is the replacement drive currently marked as 'Disk 4'

WD40EZRX-00SPEB0-WD-WCC4E0266088 - is the original drive which I took out of the array




The drives are attached to an adaptec 51245 controller - I've suspected the controller might be a bit iffy as I get awful transfer speeds between drives. I have another 51245 to hand (the vendor sent a replacement) - would a faulty controller manifest itself in this way? Would it be safe at this time to replace the controller?

(all drives were pre-cleared, and I'm re-running the pre-clear on the 'faulty' disk, which so far hasn't thrown any issues)


There's very little data on the drive itself - it had only just started to write to it after filling 'disk 3'

Link to comment

Odd - just checked the parity check history, and suggests the last check (today) was aborted by the user.


I sat and watched it at 99% - and five minutes later appeared complete - certainly don't recall cancelling it.


What should my next course of action be? Just to another parity check? Or should I Stop the array, Start it again and trigger a rebuild again?

Link to comment


I decided to go ahead and swap the raid card over.


This in itself went fine.

I restarted, selected re-build the array - but 10 mins in it's already stopped telling me 'user abort'.


Not sure how to progress. There isn't a lot of data on the drive - enough that if I lost it I can get it back - but is there perhaps a way to 'transfer' (be it from the disk or from parity) the contents to another disk with capacity (there's plenty of capacity), then 'remove'/disable 'disk 4' from the array altogether?

Link to comment
12 minutes ago, johnnie.black said:

Adaptec controller doesn't show the SMART info for any disk, so difficult to give an opinion, other than disk4 getting disabled don't see anything else out of the ordinary on the logs.


Thanks for having a look for me.


I've been through the main shares, and set them to 'exclude' disk 4. Am I safe to move the folders in the emulated disk 4 over to another disk, eg disk 3, merging them with the existing folders?

At least then the data is safe - though it's only 45gb, and most of which is still on the source system, but will save me having to piece together what's missing.


Edit: One FAQ I found (for v5, but this bit might be relevant) says that after setting the share to exclude the disk, I should transfer from disk4-->usershare (presumably letting unRaid decide where to move it to), rather than disk4-->disk3.

Does this still hold true?

Link to comment

Thanks - parity is rebuilding now.


For now, I've taken all the WD Green drives offline. Once parity is complete, I'll re-do the pre-clearing, perhaps with a few passes, to see if anything gets thrown up about them.


Are there any recommended tools for checking disks beyond the pre-clear process?

Link to comment


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

  • Create New...