I had a failed drive that was red-balled and I am replacing it with a new drive. The new drive was precleared (2 cycles) without a problem and I swapped it into place and started rebuilding my array. The new drive would be disk4.

 

On the web gui, unraid is rebuilding disk4.

 

However, on my unraid attached screen I am getting repeated runs of the following message :

 

Tower kernel: REISERFS error (device md3): zam-7001 reiserfs_find_entry: io error
Tower kernel: REISERFS error (device md3): zam-7001 reiserfs_find_entry: io error
Tower kernel: REISERFS error (device md3): zam-7001 reiserfs_find_entry: io error
Tower kernel: REISERFS error (device md3): zam-7001 reiserfs_find_entry: io error
Tower kernel: REISERFS error (device md3): zam-7001 reiserfs_find_entry: io error
Tower kernel: REISERFS error (device md3): zam-7001 reiserfs_find_entry: io error
Tower kernel: REISERFS error (device md4): zam-7001 reiserfs_find_entry: io error
Tower kernel: REISERFS error (device md4): zam-7001 reiserfs_find_entry: io error
Tower kernel: REISERFS error (device md4): zam-7001 reiserfs_find_entry: io error
Tower kernel: REISERFS error (device md4): zam-7001 reiserfs_find_entry: io error

 

I'm freaking out. I would imagine that md4 is my new drive, and md3 is my disk3.

 

When I telnet into unraid and type

> cd /mnt/disk3

I get

 

> cd /mnt/disk3
/bin/ls: reading directory .: Input/output error

 

There is a data rebuild in progress at 20%. Should I stop it? Is there any way now that I can fix this?

 

I posted my syslog from beginning to where these errors start here:

 

http://pastebin.com/WGjjawKx

 

(line 461 is where the errors begin)

 

Please help me. I know my parity is valid. disk4 is the disk being rebuilt, and disk3 is an existing spinner. should i stop the rebuild, keep the valid parity and try fixing the filesystem on disk3?

 

Any help will help save my array! Thank you so much.

I would let the reconstruction continue, then run a file-system check on disk3.  (/dev/md3)

 

Thanks Joe! I will do that and see. Does the I/O errors not interfere with the rebuild process?

 

 

Sent from my iPhone using Tapatalk

Thanks Joe! I will do that and see. Does the I/O errors not interfere with the rebuild process?

Not directly.

 

The re-construction has nothing to do with files or the file-system.  It is simply bits and bytes across all the disks. 

The file-system corruption needs to be addressed, but it can wait.  It probably had nothing to do with the disk "write" failing to the disk that was disabled.

 

Lastly, a "red-balled" disk maybe perfectly OK.  It could be a loose/intermittent power or SATA cable/connector to it, or a loose/intermittent drive tray connector.

joe,

 

so i wanted to point out a couple of things based on your advice.

 

i'm not even sure that the disk rebuild is going on properly. the webui seems oblivious to problem. all the drives are green (except for /dev/md4 which is being rebuilt) and showing up as a yellow ball.

when i look under the errors column on the webui, I see the read error count rapidly accumulating for /dev/md3 which is the array drive that was giving me the filesystem errors.

 

interestingly, on the webui, the number of "writes" for /dev/md4 (the drive being rebuilt), doesn't appear to be increasing, yet the statistics for the rebuild process (current position, data speed, and %completed is advancing). the other clue that the rebuild process is stagnant comes from my server chassis that is hot-swappable and has drive LEDs. the LED for disk4 is not currently active (which is weird since that drive should be getting rebuilt), and the LED for disk3 is solid without any blinking (suggesting that the drive is probably stuck trying to read error-after-error). The other LEDs are all active and flashing.

 

Moreover, although the webui states that the array is active, I get I/O errors when I navigate to any of the mnt/user/* folders. But I can navigate to any of the disks (/mnt/disk*) without a problem, except for disk3 and disk4, of course.

 

I could let the process go and allow the rebuild to continue on the webui, although I am not sure that it is doing anything. do you suggest that i do this?

 

Do you have any other suggestions.

 

My most recent syslog just shows a string of the following errors for /dev/md3

 

Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582720
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582728
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582736
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582744
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582752
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582760
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582768
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582776
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582784
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582792
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582800
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582808
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582816
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582824
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582832
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582840
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582848
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582856
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582864
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582872
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582880
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582888
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582896
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582904
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582912
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582920
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582928
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582936
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582944
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582952
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582960
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582968
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582976
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582984
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395582992
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395583000
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395583008
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395583016
Apr 24 17:38:02 Tower kernel: md: disk3 read error, sector=1395583024

 

I just tried getting the smart status of the disk3 (/dev/sdd) with the '-T permissive' option -- since that is the only way it will allow me to proceed, and I get this weird error;

 

root@Tower:/boot# smartctl -a -T permissive /dev/sdd
smartctl 6.2 2013-07-26 r3841 [i686-linux-3.9.11p-unRAID] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

Short INQUIRY response, skip product id

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Read defect list: asked for grown list but didn't get it
Error Counter logging not supported

scsiModePageOffset: response length too short, resp_len=47 offset=50 bd_len=46
Device does not support Self Test logging

 

 

**** UPDATE: the disk4 LED indicator started blinking every second or so, but the disk3 indicator is still solid. the number of writes on the webui haven't changed at all.