Hello,

I recently had an issue with one of my drives (4tb WD green), where it was listed as unformatted. I ran reiserfsck --check, and it told me to run with --rebuild-tree, which I did. The first time, it aborted, but finished the second time. However, the unraid GUI is still showing the drive as faulty. I re-ran reiserfsck --check, and it found no corruptions. Also, I ran the long SMART self-test on the drive, and it found no errors. Could someone please let me know what I should do next? Thanks.

unraid_log_20150127.txt

I am running unRAID 6 beta 12, and have attached my system log to my initial post.

I hope you put it in maintenance mode first. I'm running v5 unRAID and earlier this month I ran a rebuild Tree on one of my drives. But I forgot to put it in maiantenance mode first. So I lost everything on that drive. I'm still in the process of re-ripping those BD titles. next time I won't be in such a rush.

I did run in maintenance mode, and I can access all the contents of the rebuilt drive, but it's still showing as faulty. I just re-ran reiserfsck --check, and got the following error:

 

reiserfsck --check started at Wed Jan 28 12:30:12 2015
###########
Replaying journal: Done.
Reiserfs journal '/dev/md14' in blocks [18..8211]: 0 transactions replayed

The problem has occurred looks like a hardware problem. If you have
bad blocks, we advise you to get a new hard drive, because once you
get one bad block  that the disk  drive internals  cannot hide from
your sight,the chances of getting more are generally said to become
much higher  (precise statistics are unknown to us), and  this disk
drive is probably not expensive enough  for you to you to risk your
time and  data on it.  If you don't want to follow that follow that
advice then  if you have just a few bad blocks,  try writing to the
bad blocks  and see if the drive remaps  the bad blocks (that means
it takes a block  it has  in reserve  and allocates  it for use for
of that block number).  If it cannot remap the block,  use badblock
option (-B) with  reiserfs utils to handle this block correctly.

bread: Cannot read the block (460587008): (Input/output error).

Aborted

 

I'm tempted to just replace this drive, but I had to do a rebuild on another drive right before this one failed, and I'm sure my parity is out of sync. I just upgraded my system, and the specs are below:

 

System: ASUSTeK COMPUTER INC. - SABERTOOTH 990FX R2.0
CPU: AMD FX-8370 Eight-Core @ 4 GHz
Cache: 384 kB, 8192 kB, 8192 kB
Memory: 8192 MB (max. 32 GB)
Network: eth0: 1000Mb/s - Full Duplex

 

Is there any way I can still save this drive, or do I replace it and hope for the best? Thanks.

Show a screenshot of unRAID Main. Post a SMART report.

Show a screenshot of unRAID Main. Post a SMART report.

 

Thank you. The requested files are attached.

smart.txt

It is red.  SMART report look good.

 

See here: http://lime-technology.com/wiki/index.php/Troubleshooting#What_do_I_do_if_I_get_a_red_ball_next_to_a_hard_disk.3F

Thank you. Yeah, it's red. The whole array showed yellow, so that's what I was referring to. So at this point, it looks like my best bet is to rebuild the drive from parity. However, since I had to do a resierfsck rebuild on another drive prior to this one, I'm pretty sure parity isn't completely valid. Will I be OK to do a rebuild from parity, or am I going to have to use the "Trust My Array" procedure and potentially lose data? Thanks again.

You said you did a reiserfsck again nest another drive?    How did you specify that drive?  If you put the array  into Maintenance mode and did the reiserfsck against the /dev/md?  type device (which is the recommended way of doing this)  you did not invalidate parity.  If you used the raw device of the form /dev/sd?1 then parity is no longer valid and cannot be used for rebuilding a different drive.

You said you did a reiserfsck again nest another drive?    How did you specify that drive?  If you put the array  into Maintenance mode and did the reiserfsck against the /dev/md?  type device (which is the recommended way of doing this)  you did not invalidate parity.  If you used the raw device of the form /dev/sd?1 then parity is no longer valid and cannot be used for rebuilding a different drive.

 

I did put it into maintenance mode and specified it with /dev/md12. So it looks like parity should be fine. In that case I will just rebuild the second drive from parity, and hopefully that will bring the drive back online. Thanks all for your help.

So I rebuilt the drive, and I still got a red ball. I ended up replacing the drive, and plugging it into a different slot, but I still show a red ball. The drive is mounted as part of the array, and I have access to it, but it shows as red. I have a hard time believing that the replacement drive is also bad, considering it had been working just fine as my previous parity drive. I ran reiserfsck --check and it found no errors. I have also attached a smart report on the new drive. Any suggestions on how to proceed? It seems like the next best step is to run the "Trust My Array", but I want to make sure that's what I need to d. Thanks.

smart.txt

Attach a syslog.

The syslog is attached. I see a number of reiserfs warnings that seem to be triggered when I'm moving files from the "lost+found" folder back to the array.

syslog.zip

Use Tools-->New Permissions or run "newperms /usr/mnt/disk14/lost+found"

 

 

Use Tools-->New Permissions or run "newperms /usr/mnt/disk14/lost+found"

 

Thanks, I ran this command, but the drive still shows up red-balled. Should I go ahead and run the "Trust My Array" procedure?

Running reiserfsck does not clear a red-ball status - only a disk rebuild clears that.

 

What the reiserfsck did do was clear the 'unformatted' state of the emulated drive.

Thanks, I ran this command, but the drive still shows up red-balled. Should I go ahead and run the "Trust My Array" procedure?

No. The drive must be rebuilt. If you use the trust my array you WILL lose data.

I rebuilt the drive after running reiserfsck. Not only did I rebuild the drive, which did not resolve the red ball, but I replaced it and put the new drive into a different drive bay. I am able to fully access the contents of the drive, but it's still red-balled, and I am unable to test parity.

Attach a new syslog.

I rebuilt the drive after running reiserfsck. Not only did I rebuild the drive, which did not resolve the red ball, but I replaced it and put the new drive into a different drive bay. I am able to fully access the contents of the drive, but it's still red-balled, and I am unable to test parity.

if the drive is still red-balled after a rebuild, then that suggests there was a write failure during the rebuild.  If possible you should provide a syslog covering the rebuild period.

I have attached the most recent syslog. Unfortunately, I didn't think to create a syslog after the rebuild. Should I rebuild again and capture a syslog after?

syslog.zip

I have attached the most recent syslog. Unfortunately, I didn't think to create a syslog after the rebuild. Should I rebuild again and capture a syslog after?

If the drive is still red-balled then I do not think that the rebuild was successful.  I would suggest that you try the rebuild again and this time capture the syslog that covers the rebuild process.  That way we can see if there were any errors during the rebuild.  It could also be worth posting a new SMART report for the disk (possibly before and after) to see if anything is showing up there.

 

I am a bit worried about those reiserfs errors in the syslog you posted.  I am not sure what is causing them.

Thank you. I will re-rebuild the drive and capture the reports. Those reiserfs errors seem to be popping up sometimes when I move files out of the lost+found folder and back into the array. I ran new permissions per an earlier response, but that didn't stop the errors.