I recently upgraded from Unraid 5.0rc8a to 5.0.5. Disk 3 failed during the initial parity check. I know I should have done the parity check before upgrading, but it's obviously too late for that. 

 

My specific question is this: What is the easiest/safest way to replace the failed disk 3 with an empty disk 4 (they are both 2TB)? Disk 4 was already added to the array, but it has no data on it. I moved all the data that was on disk 4 to disk 5 (which is 1TB).

 

Here is a screenshot of the main page, so you can see my array:

 

 

 

 

I just want to make sure I don't remove both disks, and cause the parity backup of the disk 3 data to disappear because Unraid will think both disks have failed. Should I just move all the data via Windows Explorer disk shares? Like this:

 

 

But what if I don't want to buy a new disk right away? What will happen to the disk 3 slot, and parity?

 

Sorry, but I searched the wiki and forum, and couldn't figure it out for this specific scenario. 

 

Any help is greatly appreciated!!

 

Thanks,

Matt

Unraid_syslog_2-7.zip

Safest way: Buy a new disk and leave your array powered off until you have your new disk ready to be installed in place of disk3.  I.E. run some preclears on the disk to weed out bad disk.

 

Safer then what follows (I think anyway):  If you don't want to buy a new disk then copy the files off of the simulated disk3 to another computer.  Once all files are copied off the disk elsewhere on your network - then do an init config to destroy your array and assign your disks back to your array without disk3.  Make sure you get your parity and cache drive if you have one assigned correctly.  Start your array and let parity build again without disk 3.  Then check your parity to confirm it was built correctly.  Then copy your data back from your network to your array to fill your empty disk.

 

Least safe way (I think anyway):  Copy files from the simulated drive to your empty drive.  When that is complete do an init config and resetup your array without disk 3.  This will be less safe because you are writing to an unprotected array and you could have another drive fail and loose data on two drives.  I think just using your array to read the data is safer than to read and write to an unprotected array. 

 

My 2¢ worth.

Thanks for the quick reply, Bob!

 

So, what if:

 

• I can't afford a new disk
  
• I don't have 2TB available on any other computer on my network
  

 

Is my only option, then, the least safe one (read and write to an unprotected array)

 

Or can I somehow safely remove the empty disk 4 from Unraid, and put it in another computer? Then perform your second option.

 

Thanks again,

Matt

If disk 3 is still operational you could take it to another computer and see if you can read the files that way.  You wouldn't have any that were written to the simulated drive but existing files could still be available if it is operational.

 

Don't get me wrong you may find it will work and you have no problems but in my opinion it is the least safe option.  Your problems are why I keep cold spares on hand the size of the largest drive.  Then I've already purchased it and I don't have to purchase another drive right away.  I can save up for a while to replace the cold spare over a period of time - I would just try to make that as short as possible.

That makes sense, Bob. I was kind of waiting until drive prices come down to what they were when I bought them a couple years ago (2TB for $60).

 

In the meantime, I wanted to try a SMART test, but I'm not sure which drive is it (sda, sdb, etc). I have a screenshot from a couple days ago before the failure, but the drive designations are different than they were. Disk 3 was sdd, but now disk 2 is sdd. Is this normal??

 

Here is a side by side comparison:

 

 

Yes that is normal.  On my 4.6 unRAID array on my X7SBE MB I use to have to rearrange the disks about every 5th boot because the drives changed assignments.  Linux loads the drives based on the first one that becomes available (if I remember correctly) and if the drive or the controller doesn't connect to the drive the same way the letter will change between boots.  5.0 doesn't have that problem because it assigns drives to slots based on their ID not the drive letter.

As far as running a smart test.  You could shut down your array and just look for disk 3 with the computer OFF and take it to another computer and run some smart tests that way.  You can use the free version of unRAID on the other computer to get smart reports and run smart tests.  You have it's serial number in your graphic so you should be able to find it.

That makes sense. I'll do that now. Thanks!

The SMART text file is posted here. I'm not sure what it means. I'm going to run the long test now.

 

I added the "Windows" version of the smart.txt file.

smart.txt

Windows_smart.txt

Well, if I'm reading the SMART results correctly, then this shows that my drive is bad:

 

• Reallocated_Sector_Ct  0x0033  065  065  036    Pre-fail  Always      -      23568(RAW_VALUE)
  

 

What about shrinking my array? Here are the instructions:

 

http://lime-technology.com/wiki/index.php/Shrink_array

 

 

It seems a little bit complicated, but is this feasible for my scenario?

It would be fine.  Not sure why renaming directories is necessary for your purposes but they undoubtedly know more than I do.  When you get down to the meat of it you are to copy the data to another drive in the array then init config and remove the bad drive.  So basically what you were suggesting they just went into detail about how to do it.  Other than renaming directories it is how I would move them to a new drive and shrink the array.

 

 

The drive is definitely on it way out.  So removing it is the only option.  If it is still under warranty you should RMA.

So, I am now using midnight commander to move all my disk 3 contents to disk 4, as instructed in the wiki for "shrinking your array".

 

Since disk 3 is red balled, then the virtual files are being transferred based on parity, correct?

 

Is this why the speeds are so slow?  (10-15 MB/s)

 

Is it because it has to calculate parity before and after every file is moved? Syslog attached.

 

 

 

syslog-2014-02-09.zip

Renaming the directories ensures that as files are copied FROM the failing DISK share, they are being copied into a USER share.

That User share would/could be spread over multiple disks.  UnRAID determines whether a user share can/should/does exist on a physical disk by examining the top level directories on each physical disk.

 

By renaming the directories on the failing drive, you prevent a copy 'FROM DISK' to 'USER SHARE' from being written back to the failing drive (or from unRAID assuming its already been copied.)

 

Alternatively (to avoid renaming), in MC, you could copy FROM FAILING DISK to a specific GOOD DISK share, as long as you recreate the folder structure.

(move files into the top level USER share on the new DISK from which you are taking them off the failing drive.)  You'd also have to manage the disk space yourself.

As shown in my screenshot from MC, I am moving (F6) from the failing disk 3 to disk 4, not to a user share.

 

Any idea if the transfer speeds I'm experiencing are normal for this type of situation?

 

Not that it matters much. It'll be done by the time I wake up tomorrow. I'm just curious if I should be having quicker transfers using MC.

 

Once all my data is off the failed disk, and I reset the array configuration, and do a parity check: I'll play around with MC more to see if transfers happen quicker without a failed disk in the array.

 

Thanks,

Matt

No idea really but copying from a simulated disk should/would be slower.  Not sure it would be as slow as you are getting but it is possible.

 

 

The speed is normal in this case.