Strategy to expand a ZFS mirror pool

[yummygizzards]

I currently have two HGST Deskstar NAS 4 tb drives configured as a single vdev (ZFS mirror) in nas4free. The drives are ~2.5 years old and have no S.M.A.R.T errors and all scrubs have been clean. The pool is at ~90% capacity and I want to add another two HGST Desktar NAS 4 tb drives to enlarge the pool. There are two strategies that I can think of to accomplish this task, and I am wondering if there are any gotchas with either one or reasons one is superior to the other:

In strategy #1, I can simply create another vdev with the two new drives also as a ZFS mirror and add this vdev to the pool. This strategy would effectively double the pool size, but the vdevs would be very unbalanced at the start, and there is some risk that the new vdev might fail if one of the new drives turns out to be a lemon.

Strategy #2 would be to create a completely new pool with the two new drives, but put each drive alone in their own vdev. Then, I could create a snapshot of the old pool root dataset, “zfs send” this snapshot to the new, empty pool, export and import both pools to rename them, detach the old drives from the old pool and destroy it, and finally move the two old drives to the new pool, each old drive as a mirror for a new drive. This strategy would result in balanced vdevs but each individual vdev would have drives of two different ages and perhaps slightly different performance. Did I miss any key steps with strategy #2? Any compelling reason to pick #1 over #2 or v.v.?

 

[danswartz]

Not understanding your concern for #1. If one of the new drives is a lemon, that mirrored vdev would still be online.

 

[yummygizzards]

Not understanding your concern for #1. If one of the new drives is a lemon, that mirrored vdev would still be online.

Well, that's true. I guess I thought if a predisposition to failure occurred in this batch of drives or during shipping, both new drives would be equally prone to failure. So no good reason to go through the process of strategy #2?

 

[drescherjm]

My advice is to test your drives before using. At work and at home I test every single drive before I use with a 4 pass badblocks. This will take 40+ hours with a 4TB drive.

 

[westrock2000]

Option #3. Go buy 2 4TB drives. Copy everything from the zpool on to the 2 new drives. Reconfigure the zpool as you want. Copy everything back to the new zpool. Return the 2 harddrives saying that your motherboard was older then you thought and only recognized up to 2TB.

 

[yummygizzards]

So, it sounds like testing the drives is critical but beyond that creating a balanced vs unbalanced striped mirror is not that important.

Option #3. Go buy 2 4TB drives. Copy everything from the zpool on to the 2 new drives. Reconfigure the zpool as you want. Copy everything back to the new zpool. Return the 2 harddrives saying that your motherboard was older then you thought and only recognized up to 2TB.

Hmm, this seems "fraud-y" to me so no thanks. Plus I need the new drives to expand the pool size!

 

[FnordMan]

Option 3: Make a new array with the new drives, rename arrays as appropriate then copy data from old array to new array.

That's what i've always done when it's upgrade time.

 

[Aluminum]

You can upgrade the mirrors 1 drive at a time with resilvering, this is mentioned in quite a few ZFS guides. Once every drive in that mirror is replaced, your pool's available space is "magically" larger. No need to do any migrations to new pools with mirrors, that is only something you have to do with the raidZ# setups.

As for worrying about data problems, just don't wipe the drive you replaced until it is complete

edit: nevermind you're trying to do something different than replacement - do #1

 

[yummygizzards]

Option 3: Make a new array with the new drives, rename arrays as appropriate then copy data from old array to new array.

I think this is the same as option #2 - make a new array with two, single drive vdevs (ie no redundancy), copy data over, then break down the old array and move the drives to the new one to re-establish redundancy as mirror vdevs.

nevermind you're trying to do something different than replacement - do #1

I am leaning towards option 1 and perhaps copying data around within the new pool to help rebalance the two mirror vdevs afterwards. Making a new pool and copying things over is more complicated and prone to mishaps...