I have more capacity than I need and disk4 is dying anyhow (Reallocated sector count from 0 to 531 in the last 2 days, Current pending sector is still 0). Instead of placing disk4 with a new 3TB drive I would like to remove that particular drive from the array.

 

I have moved all data to other disks of my array so that disk4 is empty. Is it possible to skip step 3 from the guide below and just go ahead with #4 after having brought the array into Maintenance mode?

[*]Start array in Maintenance mode.

[*]Identify which disk you're removing (disk4) and take a screen shot.

[*]From the command line type: dd bs=1M if=/dev/zero of=/dev/md4

[*]When the command completes, Stop array, go to Utils page, click 'New Config'.

[*]Go back to Main, assign Parity, and all devices except the one you just cleared.

[*]Click checkbox "Parity is already valid.", and click Start

You can only skip step 3 if you do a new parity sync, in that case can skip steps 1 to 3, and on step 6 don't check the "parity is already valid" box, array will be unprotected during the parity sync.

 

For the parity to remain valid you must do all steps, in which case I recommend enabling turbo write before, it will take about half as long to zero disk4.

Thanks johnnie.black.

 

So you would recommend to follow that guide?

 

Turbo write is available on 6.2beta only or am I wrong?

If you want to maintain parity it's the only way.

 

Turbo write is a setting on v6.2-beta, it can also be enable on v6.1 by typing in the console:

 

mdcmd set md_write_method 1

Great, that will speed up the whole process.

 

Last question: is it sure that disk4 equals md4 by using that command?

dd bs=1M if=/dev/zero of=/dev/md4

Last question: is it sure that disk4 equals md4 by using that command?

dd bs=1M if=/dev/zero of=/dev/md4

 

Yes

Sounds like you've got it, but just wanted to say that procedure should only be used by people who understand what it's doing and why it works.

 

We recently had another user try to use that advanced procedure to remove a drive and wound up losing data because he somehow assumed the dd command was going to take care of moving his data off the drive he was zeroing. The thread he was following didn't really discuss moving the data before zeroing and so he didn't do it.

Thanks for taking care trurl, but as said in my initial post: "I have moved all data to other disks of my array so that disk4 is empty."

 

Should be all good and johnnie.black's confirmation that md4 = disk4 removed the last uncertainty. Additionally I have to say that my 2nd server (test&backup) contains the data as well.

 

Plan is to continue with 4 data disks and replacing the installed 3TB disks with 6TB or any other larger disks in case I need more space.

 

By removing one disk I have a slot available for double parity as soon as 6.2 is available.

Short feedback: I have launched the dd bs=1M if=/dev/zero of=/dev/md4 about 10h ago and the process is still running.

 

Meanwhile the disk is showing 1.592 reallocated sectors, a raw read error rate of 4.260.063. The unRaid Dashboard is showing 86.016 errors.

 

How long is the time that is still needed? Is see 5.042.883 reads and 5.040.316 writes. How much need to be read and written for a 3TB disk?

With turbo write enable it takes as long as a parity check, about twice that or more with it disable.

 

If disk4 is bad it can take longer, and if it's really bad it's probably best to remove the disk and do a new config and a parity sync.

 

Well it was running already now double the time that a parity check usually needs.

 

If I would just knew how many reads/writes are needed for a 3TB drive I could decide to cancel the process or waiting.....

There's no way of knowing by the number of writes, as different controllers/disks can give very different values, sometimes even with the same disks/controllers.

 

With v6.2 there's a way to show progress using:

 

dd bs=1M if=/dev/zero of=/dev/mdx status=progress

 

I believe there's also a way on v6.1 using pv but don't know how.

Good that I had some patience 

root@Tower:/# dd bs=1M if=/dev/zero of=/dev/md4
dd: error writing ‘/dev/md4’: No space left on device
2861589+0 records in
2861588+0 records out
3000592928768 bytes (3.0 TB) copied, 56107 s, 53.5 MB/s
root@Tower:/# 

 

I will continue now with stopping the array and defining the "New Config" from Utils page.

If disk4 is bad it can take longer, and if it's really bad it's probably best to remove the disk and do a new config and a parity sync.

This, exactly. It's false security to think you are helping matters by zeroing a bad disk to keep parity valid. Every extra minute that the array runs with a bad (or partially bad) drive is risking a second drive failure. Since the drive to be removed will never need to be reconstructed, it's far better to rewrite parity with all the drives you do want to protect than to spend the time zeroing a drive you will be removing.

Thanks a lot to johnnie.black and jonathanm.

 

The whole process went really well and I am back with Parity Write speed of 150MB/s in average and more importantly....w/o any errors.

 

Only thing that I missed is to exclude drive slot #4 (see pic.)

 

Do I have to redo the following steps? Thanks for the final advise.

• Stop array, go to Utils page, click 'New Config'
  
• Go back to Main, assign Parity, and all devices
  
• Click checkbox "Parity is already valid.", click Start

It's not a big deal that you didn't assign a drive to slot #4 => all will work just fine without it.

 

Some folks would be a bit OCD about having a missing drive #, but technically it makes no difference.

 

Next time you add a drive just put it in slot #4.

 

One way you could fix this is wait for the parity sync to finish;  Stop the array; do a New Config and assign all of the drives to the slots you want ... being CERTAIN you assign the same parity drive; and then you can check the "parity is already valid" box and Start the array.

 

Since you should do a parity check after the sync to confirm all went well anyway, you could do the New Config with "parity is already valid" and THEN do the confirming parity check.

 

Thanks garycase, unfortunately I missed to check "Parity is already valid" 

 

Parity Sync is running now so that I should be fine in 5h from now. Will run another Parity Check afterwards.

lol, you realize in the end you did what you were trying to avoid with this whole procedure 

Indeed, silly me