From owner-freebsd-fs@freebsd.org Tue Sep 22 10:32:15 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE25BA06331 for ; Tue, 22 Sep 2015 10:32:15 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 57C95158A; Tue, 22 Sep 2015 10:32:15 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: by wicgb1 with SMTP id gb1so153141297wic.1; Tue, 22 Sep 2015 03:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8U8QiWxGDqawZjkqjJ/9wHct9v2idHCxcHcHxaM5A2Q=; b=yl1WDn5H7T4mtkNpz6NeApwhgFHM48N0c0C3K2rBslNt7iaNwmo2fDI2sRSwjffqLd Oj3tm1qHZ91iwrnuzYyJBEt/+omu7K2oc9kVmnI7s87VgOWMAx0WF9HMaB3wCb3H6TSh Rf9jkpd/CFXlhb43XASzsvvthbiZoH230mRyvT/YetquJ6GxSDl4BQXmVdQgs8QwtTcq DotmJSeg0YNX+LfqZ+G7DtDT4tOGqUTFXBOeXqDEvnJ5qw/TK2KuH+nbzj0gVzGYXgJm 9IhGpuUsXywRgFEXvrRLIKxYuOJF2Z2BbKDqfDhjl9cnrgEvBuMpEcMxueKfHYy0E4kG o5OA== MIME-Version: 1.0 X-Received: by 10.180.198.109 with SMTP id jb13mr19343550wic.17.1442917933760; Tue, 22 Sep 2015 03:32:13 -0700 (PDT) Received: by 10.28.125.18 with HTTP; Tue, 22 Sep 2015 03:32:13 -0700 (PDT) In-Reply-To: <5600798B.3010208@FreeBSD.org> References: <20150921170216.GA98888@blazingdot.com> <20150921211335.GB41102@server.rulingia.com> <5600798B.3010208@FreeBSD.org> Date: Tue, 22 Sep 2015 11:32:13 +0100 Message-ID: Subject: Re: ZFS cpu requirements, with/out compression and/or dedup From: krad To: Matthew Seaman Cc: FreeBSD FS Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 10:32:15 -0000 or far more easily do an rsync from the old to the new with the remove-source-files option, and then drop the old dataset at the end On 21 September 2015 at 22:41, Matthew Seaman wrote: > 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 > > >