So I may have really messed something up. My array has been running great for months now and yesterday I upgraded one of my disks (md6): Shut down the system, put the new disk in, checked format and then it started to rebuild. Everything was going well till the power went out. When it came back on, I rebooted the system.

 

Here's where the problems began. I saw the option to format again and pressed it without thinking assuming it was just repeating the same process as before the power outage. I went to bed and when I got up in the morning, the rebuild had only progressed 1%. This was an obvious red flag and then I realized that on the main page, disk /md10 (a disk which has been in the array for months) was showing that it was unformatted although it's light was green and the page said the array was valid. I did some forum searching and found people had had success simply restarting the system. I did so (though the main web interface page was taking a looong time to respond now).

 

When the system rebooted, it started automatically into the parity rebuild, but /md10 was still showing unformatted (but green) and was logging up thousands of errors. Did something happen to /md10 during the power failure to mess it up? When I pressed the format button after the power outage, it very well could have been md10, not md6 that was showing unformatted. Can I save my data? Because now I have a new disk (md6) that hasn't been rebuilt and a disk with problems (md10).

 

After more forum searching, I ran -reiserfsck --check on md10 and got a bad block error:

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

 

In any other case, I  would just replace the disk, but I can't because of course I have the other new disk in the system.

 

Any thoughts?

Thanks in advance!!!!

 

Here's my syslog

https://files.me.com/apatrickrose/x1br5j

 

Can you explain the exact steps you took? Also what version of unraid are you running? Normally, when you upgrade a disk, you just replace it with the new one and start the array. The array does not rebuild parity since it uses parity plus the other disks to rebuild the upgraded disk. By hitting format, you may have inadvertently told unraid to format the new disk and then rebuild parity with the formatted disk thereby ruining the parity. Hopefully you kept the old disk around.

 

While you could have used the old disk and the parity drive to rebuild md10, the parity may not be valid any longer.

 

Double check that you didn't jostle md10's data cable or power when you swapped md6. Then retry running reiserfsck if you think it was a data/power cable issue.

 

Other than that, hopefully others have suggestions.

 

Also, if you don't have a UPS, invest in one ASAP.

Sry, I adjusted my post for better wording. The array wasn't rebuilding the parity, it was rebuilding the the files on the new disk.

 

But yeah, I think I am in trouble with 2 disks not functioning. The old disk I was replacing had gone bad so it's of no use unfortunately.

 

I will be getting a UPS.

Was the parity rebuild actually happening, or do you mean something else like repeated attempts to build disk6? If it was a parity build, then the parity has already be modified to reflect the messed up disks and you can't save the data on either new disk.

 

If you meant repeated attempts to build disk6, then you can try to get disk10 working again so the array is good. I would try disk10 on a new port with new cables and see if it comes alive again. If it does, then I would put the old disk6 back in and use the trust my parity procedure and allow the parity check to complete to make sure it matches to the disks and the array is healthy. Once the array is healthy again, you could try upgrading disk6 once more.

 

If you can't get disk10 to come back then you might be able to rebuild it onto a new disk. Put the old disk 6 back in, a new disk in place of disk10 and then use the trust my array procedure, except use 10 instead of 99.

 

"mdcmd set invalidslot 10"

 

This will tell unRAID to rebuild disk10 instead of doing a parity build.

 

http://lime-technology.com/wiki/index.php?title=Make_unRAID_Trust_the_Parity_Drive,_Avoid_Rebuilding_Parity_Unnecessarily

 

Before you start the array, I would use the utility Joe wrote listed at this post to create a partition on  the disk you are using to replace disk10. The forced rebuild doesn't seem to create the partition, so that has to be done manually.

 

http://lime-technology.com/forum/index.php?topic=5072.msg47122#msg47122

 

Peter

 

Thanks for the incredibly snappy responses guys!

 

I tried your suggestion, lionel, and moved disk 10 to a different slot. The rebuild on disk 6 looks very normal now and is completing at a rate consistent with what I've experienced in the past (4hrs roughly). The web interface is responding normally as well.

 

Disk 10 is no longer listing any errors during the rebuild process. Everything would be completely normal if only disk 10 didn't still say Unformatted.

 

I guess I will let the disk 6 rebuild finish and see where we are in the morning.

 

Sorry it's been a while since getting back.

 

The rebuild appeared to go normally.

md10 still showed up as unformatted so I just reformatted md10 and rebuilt it.

Interestingly enough md3 then appeared as unformatted. Though I ran a reiserfsck --check on it which told me to to run a --rebuild-tree which I did and it seemed to be ok. There was nothing in the lost+found directory.

 

The array appears to be normal on the interface and on boot up. I can browse files, but as soon as I try to write to it, windows explorer stops responding and I can no longer access the server.

 

I'm not sure if this is a new problem or a continued result of what I had done before.

I'm so confused, lol.

I've attached a new syslog.

 

Thanks!

2011-5-12.txt

You've got 2 kernel Oops at the end of the log that don't look good.

 

I'd first try doing reiserfsck checks on all your disks and see if there are more filesystem problems.

 

Peter

will do. I'll let you know

thanks