Date: Tue, 2 Nov 2010 15:29:52 -0700 From: Freddie Cash <fjwcash@gmail.com> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: Converting a non-HAST ZFS pool to a HAST pool Message-ID: <AANLkTi=H-ZpKmwYL9Ts=H4FCwibuTZx0x_5LD0pLUHgb@mail.gmail.com> In-Reply-To: <20101102220657.GC2051@garage.freebsd.pl> References: <AANLkTin07ZvB%2Bj2sqdi2bSS_4MwEvEcRPgK-0qc%2Brch4@mail.gmail.com> <20101016222833.GA6765@garage.freebsd.pl> <AANLkTiknuYV53NErau%2BfHLX74yLguv0t0Oi_3exK8%2BEp@mail.gmail.com> <20101102220657.GC2051@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 2, 2010 at 3:06 PM, Pawel Jakub Dawidek <pjd@freebsd.org> wrote=
:
> 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 o=
nes?
>>
>> =C2=A0- zpool offline poolname label/disk01
>> =C2=A0- physically replace drive
>> =C2=A0- glabel drive as disk01
>> =C2=A0- configure hast to use label/disk01
>> =C2=A0- 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. =C2=A0But
>> thought I'd double-check, just to be safe. =C2=A0:)
>
> 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. =C2=A0And more going in eve=
ry
>> day. =C2=A0So it might be better to start fresh.
>
> If you mean HAST initial sync, then this should be now improved in
> r214284:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Before this change on first connect between pr=
imary and
> =C2=A0 =C2=A0 =C2=A0 =C2=A0secondary we initialize all the data. This is =
huge waste of time
> =C2=A0 =C2=A0 =C2=A0 =C2=A0and resources if there were no writes yet, as =
there is no real
> =C2=A0 =C2=A0 =C2=A0 =C2=A0data to synchronize.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Optimize this by sending "virgin" argument to =
secondary, which
> =C2=A0 =C2=A0 =C2=A0 =C2=A0gives it a hint that synchronization is not ne=
eded.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0In the common case (where noth nodes are confi=
gured at the same
> =C2=A0 =C2=A0 =C2=A0 =C2=A0time) instead of synchronizing everything, we =
don't synchronize
> =C2=A0 =C2=A0 =C2=A0 =C2=A0at 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.
Ah, I see what you mean. I was originally thinking of replacing the
drives in the "master" server, then configuring the "slave" server,
and then syncing the two. Which would take aeons to do.
Instead, it can be done in a piecemeal fashion:
- configure slave server using new hardware (all 1 TB drives, for example=
)
- replace 1 drive in master server, configure drive as a HAST device
- use the HAST device to replace the non-HAST device in the ZFS
pool, which causes ZFS to resilver it
- this would then start a HAST sync *of just that one drive*
- wait for resilver and sync to complete
- replace next drive in master server
- same process as above
- repeat until all drives in master server are replaced with larger
drives, using /dev/hast/* devices
At that point, the master server should be using all HAST devices to
form the ZFS pool, and have a bunch of extra free space as a bonus.
*And*, the HAST devices should be all sync'd up with the slave server.
During this process, I'd have to make sure that no automatic fail-over
is setup, as it needs to sync master-->slave first. But, once the
sync is done, then the CARP setup and fail-over can be done.
--=20
Freddie Cash
fjwcash@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=H-ZpKmwYL9Ts=H4FCwibuTZx0x_5LD0pLUHgb>