I read this thread with interest, and posted this question there. However, since it's a dying forum there now, there were nor responses. I'm hoping for some luck here.

The thread linked to above describes a method of zeroing a drive while it's still in the array if you wish to replace it, without losing parity protection at any time. I'm in this situation. I just used up my last vacant slot with a 2 TB drive and copied all the data from two 1 TB drives to it. Now I want to remove the two 1 TB drives, freeing up a slot to expand yet another 2TB drive and leaving an extra slot for preclearing.

I was wondering whether there is any added risk of zeroing out both 1 TB drive simultaneously (using separate telnet connections), or indeed whether it's possible to do so.

I want to remove these drives from my array ASAP, as I don't want any new files written to them now that their data have been copied onto a 2 TB drive.

Since unRAID is EVEN Parity based, there is a faster trick you can use if you want to remove 2 drives at once that are the same size. You mirror the entire first drive to be removed onto the second drive to be removed. Then you're able to remove both drives at the same time and trust your parity that you left intact. I'll let Joe L give the full step by step details.

 

dd bs=2048k if=/dev/mdX of=/dev/mdY

 

mdX = first drive to be removed, ie: /dev/md7

mdY = second drive to be removed, ie: /dev/md12

 

Since unRAID is EVEN Parity based, there is a faster trick you can use if you want to remove 2 drives at once that are the same size. You mirror the entire first drive to be removed onto the second drive to be removed. Then you're able to remove both drives at the same time and trust your parity that you left intact. I'll let Joe L give the full step by step details.

 

dd bs=2048k if=/dev/mdX of=/dev/mdY

 

mdX = first drive to be removed, ie: /dev/md7

mdY = second drive to be removed, ie: /dev/md12

 

That trick will work if the disks are exactly the same size.  (and I don't think I've ever seen it mentioned before)

You can clone the one disk onto the other, and then remove BOTH at the exact same time, then use the "trust parity" procedure as described in the wiki.

 

Just be VERY CAREFUL which device you overwrite, and which you clone from.  If you use the wrong disks, parity will be wrong and you'll clobber your own data.

 

Joe L.

Either clear them one at a time or copy the one to the other as suggested. Clearing both at once will thrash the hell out of your parity drive and cause it to go much slower. I wouldn't be surprised if clearing both at once takes 3 or 4 times as long as clearing one then the next.

 

Peter

Thanks everyone. That's a cool trick, BRiT. Both drives are WD10EADS drives and unRAID sees them as the exact same size. I'll try this tonight.

I was tempted to just remove the drives and rebuild parity - that way the data on them would remain intact for a while in case there was a problem with the 2TB drive. But I guess that's what parity is there for.

I've just started doing this, but have noticed that another one of the drives in the array is clicking loudly.

I think I should be okay, though even if it means having to replace the clicking drive once the drives have mirrored one another. If the clicking drive fails before the mirroring is done, I'll simply remove those two drives, replace the failed drive, rebuild its data and then go on as usual, right?

Be careful.

 

The mirroring should be OK to complete because that will involve the parity drive and the 2 data drives.

 

It will be a pain to replace the failed drive and remove the 2 mirrored drives at the same time. So, I would let the clear finish and then rebuild that failing/failed drive. Remove the 2 drives once the array is healthy again.

 

Peter

 

 

The mirroring finished according to my telnet window, but it didn't show properly in my web interface. I screwed up with the mirroring, I think. I used the device identifiers for the correct disks - sdi and sdj, but now see that I should have used mdx and mdy where x and y are the disk numbers in the unraid interface - is that correct?

 

In any case, I tried to stop and restart the array. The drives took forever to unmount, and I had to force a shutdown, since some construction work in the house required a shutting off of power. When I restarted the array took more than half a day to mount all the disks, with lots of clicking coming from the server. A parity check showed ten million sync errors and 268 parity errors after 4% completion, and the check itself was crawling along at down to 100 kb/sec

The two mirrored drives show exactly the same free space now though.

 

What are my options? I'm thinking I should check the logs to see if I can identify which is the troubled disk. I'm not sure that I can trust parity now, though. If the trouble with the clicking disk is only when it's being written to, I may be able to transfer the data off it.

The mirroring finished according to my telnet window, but it didn't show properly in my web interface. I screwed up with the mirroring, I think. I used the device identifiers for the correct disks - sdi and sdj, but now see that I should have used mdx and mdy where x and y are the disk numbers in the unraid interface - is that correct?

 

In any case, I tried to stop and restart the array. The drives took forever to unmount, and I had to force a shutdown, since some construction work in the house required a shutting off of power. When I restarted the array took more than half a day to mount all the disks, with lots of clicking coming from the server. A parity check showed ten million sync errors and 268 parity errors after 4% completion, and the check itself was crawling along at down to 100 kb/sec

The two mirrored drives show exactly the same free space now though.

 

What are my options? I'm thinking I should check the logs to see if I can identify which is the troubled disk. I'm not sure that I can trust parity now, though. If the trouble with the clicking disk is only when it's being written to, I may be able to transfer the data off it.

You completely messed up parity by using the /dev/sdX devices.  There is no parity protection at all right now until you let a full parity check complete.

 

Sorry to give you the bad news... but at this point you might as well stop the array, un-assign the two drives you wanted to remove, then set a new initial configuration and calculate parity from the remaining disks.

 

As far as the slowdown... post a syslog.  You might have lost a disk.  You may have lost the data on it too since there is no parity to re-construct from.

 

Joe L.

Thanks, Joe L

 

I figured that's what happened afterwards. I just wasn't familiar with the md nomenclature - I thought that it was equivalent to the sdx and hdx.... and I'm really used to using the sdx form from the preclear script. Oh well... live and learn. I don't know if I can complete a parity check or rebuild at a few kb per sec, but I'll see what I can do. At least if I can read the data I might be able to transfer it to somewhere.

 

I'm importing all the yet to be imported media into my J. River Media Center. That way, if the clicking disk fails, I'll see what's missing and can then at least re-rip, re-download or reload everything.

Well, it seems I got very lucky - mostly.

 

I removed the two drives today and restarted a parity sync. It's moving along faster than ever before... and it turns out that the clicking drive is actually just my cache drive. Normally, after transferrign a file to the cache, I don't delete it until it's been safely moved to the array. So now, if the drive crashes during the next move to the array, I'll have most of the stuff backed up. In the worst case scenario, losing just 300 GB of media, which can be replaced, compared to a minimum of 1 TB if any of my other drives failed is a win in my book.

 

Lesson learned, and next time I zero two drives, I'll do it properly!

You did do it properly. Parity was preserved. If a data disk had failed you could recover. You would have lost a failed disk if you had done an initconfig and the data disk failed during parity build.

You did do it properly. Parity was preserved. If a data disk had failed you could recover. You would have lost a failed disk if you had done an initconfig and the data disk failed during parity build.

 

No, I think I did screw it up if I'm not mistaken: I used the sdx format to identify the disks to be duplicated, rather than the mdx nomenclature. From what I understand, the mdx and mdy would have kept the parity disk updated during the duplication, but the sdx and sdy identifiers somehow did not. In any case, the parity was very badly screwed up. A parity check yielded millions of errors after just a few percent completion. Now, I've got to rebuild parity after removing those drives to make it all good again. I'm going to get the chance to do it right very soon, as I have a number of 1TB drives to replace with 2TB ones.

I read it wrong. Yes, you needed to use the md devices to get it to work right.

 

Good to hear it's the cache only but wow, Where'd you buy those > 300T in size drives?

 

Peter

Haha... thanks. I've edited the offending units.