ZFS cpu requirements, with/out compression and/or dedup

Matthew Seaman matthew at FreeBSD.org
Mon Sep 21 21:41:51 UTC 2015


On 21/09/2015 22:13, Peter Jeremy wrote:
> In general, the downsides of dedup outweigh the benefits.  If you already
> have the data in ZFS, you can use 'zdb -S' to see what effect rebuilding
> the pool with dedup enabled would have - how much disk space you will save
> and how big the DDT is (and hence how much RAM you will need).  If you can
> afford it, make sure you keep good backups, enable DDT and be ready to nuke
> the pool and restore from backups if dedup doesn't work out.

Nuking the entire pool is a little heavy handed.  Dedup can be turned on
and off on a per-ZFS basis.  If you've a ZFS that had dedup enabled, you
can remove the effects by zfs send / zfs recv to create a pristine
un-deduped copy of the data, destroy the original zfs and rename the new
one to take its place.  Of course, this depends on your having enough
free space in the pool to be able to duplicate (and then some) that ZFS.

Failing that, you might be able to 'zpool split' if your pool is
composed entirely of mirrors.  So long as you're able to do without
resilience for a while this basically doubles the space you have
available to play with.  You can then destroy the contents of one of the
split zpools, and zfs send the data over from the other split pool.
Unfortunately there isn't a reciprocal 'zfs rejoin' command that undoes
the splitting, so you'll have to destroy one of the splits and re-add
the constituent devices back to restore the mirroring in the other
split.  Which is a delicate operations and not one which is forgiving of
mistakes.

And failing that, you can start pushing data over the network, but
that's hardly different to restoring from backup.  However, either of
the first two choices should be significantly faster if you have large
quantities of data to handle.

	Cheers,

	Matthew


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 957 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20150921/bd9323e5/attachment.bin>


More information about the freebsd-fs mailing list