assur191 Posted January 28, 2015 Share Posted January 28, 2015 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 Link to comment
assur191 Posted January 28, 2015 Author Share Posted January 28, 2015 I am running unRAID 6 beta 12, and have attached my system log to my initial post. Link to comment
aaronwt Posted January 28, 2015 Share Posted January 28, 2015 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. Link to comment
assur191 Posted January 28, 2015 Author Share Posted January 28, 2015 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. Link to comment
dgaschk Posted January 29, 2015 Share Posted January 29, 2015 Show a screenshot of unRAID Main. Post a SMART report. Link to comment
assur191 Posted January 29, 2015 Author Share Posted January 29, 2015 Show a screenshot of unRAID Main. Post a SMART report. Thank you. The requested files are attached. smart.txt Link to comment
dgaschk Posted January 29, 2015 Share Posted January 29, 2015 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 Link to comment
assur191 Posted January 30, 2015 Author Share Posted January 30, 2015 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. Link to comment
itimpi Posted January 30, 2015 Share Posted January 30, 2015 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. Link to comment
assur191 Posted January 30, 2015 Author Share Posted January 30, 2015 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. Link to comment
assur191 Posted February 9, 2015 Author Share Posted February 9, 2015 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 Link to comment
assur191 Posted February 9, 2015 Author Share Posted February 9, 2015 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 Link to comment
dgaschk Posted February 10, 2015 Share Posted February 10, 2015 Use Tools-->New Permissions or run "newperms /usr/mnt/disk14/lost+found" Link to comment
assur191 Posted February 12, 2015 Author Share Posted February 12, 2015 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? Link to comment
itimpi Posted February 12, 2015 Share Posted February 12, 2015 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. Link to comment
JonathanM Posted February 12, 2015 Share Posted February 12, 2015 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. Link to comment
assur191 Posted February 12, 2015 Author Share Posted February 12, 2015 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. Link to comment
itimpi Posted February 12, 2015 Share Posted February 12, 2015 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. Link to comment
assur191 Posted February 12, 2015 Author Share Posted February 12, 2015 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 Link to comment
itimpi Posted February 12, 2015 Share Posted February 12, 2015 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. Link to comment
assur191 Posted February 12, 2015 Author Share Posted February 12, 2015 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. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.