Converting a non-HAST ZFS pool to a HAST pool

[Pawel Jakub Dawidek]

On Tue, Nov 02, 2010 at 02:52:45PM -0700, Freddie Cash wrote:
> Okay, so converting a non-HAST ZFS setup to a HAST setup using the
> same drives won't work.
> 
> Any reason that it wouldn't work when replacing the drives with larger ones?
> 
>  - zpool offline poolname label/disk01
>  - physically replace drive
>  - glabel drive as disk01
>  - configure hast to use label/disk01
>  - zpool replace poolname label/drive01 hast/drive01
> 
> I can't think of any reason why it would fail, since the hast device
> will be twice as large as the non-hast device it's replacing.  But
> thought I'd double-check, just to be safe.  :)

Yes, this should work.

> Granted, doing it this way would required a *long* initial sync, as
> there's currently 18 TB of data in the pool.  And more going in every
> day.  So it might be better to start fresh.

If you mean HAST initial sync, then this should be now improved in
r214284:

	Before this change on first connect between primary and
	secondary we initialize all the data. This is huge waste of time
	and resources if there were no writes yet, as there is no real
	data to synchronize.

	Optimize this by sending "virgin" argument to secondary, which
	gives it a hint that synchronization is not needed.

	In the common case (where noth nodes are configured at the same
	time) instead of synchronizing everything, we don't synchronize
	at all.

The change is not yet merged to stable/8, AFAIR, but this will happen
today or tomorrow.

You still need to wait for ZFS to copy the data over to the new vdev.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20101102/403e93c0/attachment.pgp