On Tue, 19 Oct 2010, Trond Michelsen wrote:>
> Anyway - I''m wondering what is the best way to migrate the data in
> this system? I''m assuming that upgrading a raidz1 vdev to raidz2
is
> not possible, and I have to create a new pool, zfs send all the
> datasets and destroy the old pool. Is that correct?
Yes, this is the best way.
> The current pool holds 16TB, and with 2*6 2TB drives in raidz2, I
> should also get 16TB, so it should be possible to just zfs send all
> datasets to the new pool, destroy the old, and add the 1,5TB drives to
> the new pool. This should be fairly straightforward, but the way I
> understand it, if I do this, I''ll end up with two completely full
> vdevs and two completely empty, and I''d prefer if the vdevs were
> fairly evenly balanced.
Yes, the data would be unbalanced. You will need to balance the cost
of the unbalanced data with the cost (time and effort) required to
re-balance it. Assuming that the new drives perform similarly to the
old drives, then the unbalanced pool should perform the same (or
better) than the old pool. The unbalanced pool might perform better
than the old pool because the data written by the ''send'' is
likely to
be arranged much better on disk (e.g. less fragmentation). On the
flip side, it is not uncommon to find that today''s larger drives
perform less well than yesterday''s smaller drives. If you need better
overall performance than before (more available peak IOPS), then it is
necessary to rebalance.
> What''s the best way to balance the pool? Creating a temporary pool
> with the 1TB-drives, zfs send each dataset there, destroy it from the
> mainpool and zfs send it back?
Using a temporary pool does seem like a best approach.
> This will copy all data three times (once for the first migration,
> then out and back in again), so it''ll probably take a few days.
But,
> if I understand how zfs writes data to the vdevs correctly, they
> should be at least become pretty well balanced at the end of the
> process.
>
> Are my assumptions correct? Are there any better/faster ways?
The idea that it will take "a few days" is likely a gross
underestimate of the time required. The time required depends quite a
lot on the performance of the disks involved, and if the pool was made
more complex by using snapshots, or if the original pool was ever
allowed to become excessively full (and thereby fragmented).
Bob
--
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/