Expanding zfs+geli pool

[Matthew Seaman]

On 06/19/15 17:01, Emre Gundogan wrote:
> I have a 4-disk (2TB each) striped mirrored zfs pool consisting of geli
> vdevs in the following configuration:
> 
> pool:
>   mirror1:
>      disk1 (2TB)
>      disk2 (2TB)
>   mirror2
>      disk3 (2TB)
>      disk4 (2TB)
> 
> I'd like to replace those disks with 4TB ones to essentially double the
> capacity of the pool. What's the recommended order of disks to 'zpool
> offline/replace/resilver (automatic)' in this case? In sequence, or can
> I replace them in the following order: disk1 -> disk3 -> disk2 -> disk4
> ?  Considering that two of the 4TB disks I am thinking of using in the
> grown pool are few months older than the others, I thought putting the
> older ones in separate mirrors would reduce the risk of pool becoming
> unavailable when they fail (possibly both together at the same time).
> Does this make sense, and is it possible to replace them in the odd
> order I described? Just a note: I only have 4 SATA ports available on
> this machine, and therefore can't have both old and replacement disk
> plugged in at the same time.

So long as you ensure that only one drive out of each vdev is replaced
at a time, and that resilvering has completed before you replace the
other one, then, subject to those constraints, the ordering doesn't
matter.  The order you describe would work fine.

Ideally, yes, adding the new drives to the mirror before removing the
old ones would be better, but as your hardware doesn't support that,
you're going to have to accept a period of lower resilience while all of
the resilvering goes on.

Yes, making each mirrored vdev contain on new and one older drive would
be sensible.

Check the setting of the 'autoexpand' property on the zpool before you
begin.  I your shoes I'd set autoexpand=off and then issue an explicit

  zpool online -e pool disk1 disk2 disk3 disk4

after all the resilvering is done so that you're in control of when the
expanded space becomes available.

	Cheers,

	Matthew




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20150619/631f45b5/attachment.sig>