Hi Team,

 

I have unraid 5.0.5 and had a data drive failure and went to replace it with a drive bigger than my parity drive, and so went to follow the swap-disable process here (http://lime-technology.com/wiki/index.php?title=UnRAID_Manual#Replace_a_failed_disk).

 

I initially precleared the new drive, which was all good...

 

then when I execute the swap-disable via webgui, it all seemed to be OK initially, got to about 70% copy complete of the old parity to the new parity drive, then there was no response from the webgui from there on in.

 

So I logged on via console to see if I could see what was going on..

 

1. I used the mdcmd to try to get the status, when I ran the following command, i got the following output:

/root/mdcmd status | egrep "mdResync|mdState|sbSync"

 

sbSynced=1452812115

sbSyncErrs=0

mdState=SWAP_DSBL

mdResync=0

mdResyncCorr=0

mdResyncPos=0

mdResyncDt=0

mdResyncDb=0

 

 

noting that the sbSynced value never changed (not sure if it was supposed to)

 

2. I then checked the syslog, and noticed the following:

Unraid emhttp: copy: disk3 to disk0

followed by:

Unraid emhttp: copy: 3% complete

Unraid emhttp: copy: 4% complete

and onward up to 99% complete.

 

So I'm not sure if this was rebuilding the new parity drive as was shown on WebGui, or rebuilding of the old parity drive to become the new data drive... but it got to 99% and never actually finished or showed any further output.

 

I left the system for another 24 hours or so just in case it was still 'doing something' although the hard drive lights had stopped...

 

The webgui was still unresponsive...

 

3. So then I thought maybe I should just restart the webgui, and hopefully it would 'figure out' the right status of the swap-disabled drives and I could restart everything...

so I did a 'killall emhttp' then 'nohup /usr/local/sbin/emhttp &'

Which successfully brought the WebGui back up... BUT it had the OLD configuration with the old parity drive and missing data drive, and it started up the array.

 

HELP!

 

I'm not even sure of the status of my drives, whether I've successfully copied the parity from the old parity to the new parity drive... and if that was a success, whether or not the rebuild of the data drive has happened or not... and also now whether the restart of webgui has messed anything up...

 

I'm hoping that it's the parity rebuild that got to 99% and didnt finish, and I can just run this again, but how do I know?, and how do I know if the parity hasnt been 99% overwritten with data instead?

 

From the timing of it, i would have to say that the 99% complete above seemed to be the data rebuild, because I got to 70% parity copy relatively quickly via webgui, then it took a LONG time monitoring the syslog for it to get to 99%...

 

Help!?

Can/should I re-enable the old drive config as WebGui thought it was, and do some check? or what would be my next step here to avoid data loss?

 

I've attached the key bits of syslog for reference..

syslog.txt

Update:

Based on the syslog comments from this post (http://lime-technology.com/forum/index.php?topic=9135.msg87402#msg87402) and this post (http://lime-technology.com/forum/index.php?topic=29781.msg267726) I think that the parity copy didnt finish, that emhttp maybe timed out or ran out of memory or something, so presumably I could just try it again? Or should I really just try to find a smaller drive somewhere to rebuild this array 'simply' first, and avoid the two-step of swap disable?

The copy may have finished but you’d have to click start to rebuild the old parity disk, so your old parity is intact and I believe best option is to try again, maybe after booting into safe mode, or rebuild to a smaller disk.

Thank you Johnnie... that gave me confidence to retry the swap-disable (this time in safe mode)... parity-copy is 49% and WebGUI still accessible - so far so good!

Thank you again... swap-disable fully completed and data rebuild complete!