From owner-freebsd-fs@freebsd.org  Mon Sep 21 12:50:40 2015
Return-Path: <owner-freebsd-fs@freebsd.org>
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 5C58F9D0A49
 for <freebsd-fs@mailman.ysv.freebsd.org>; Mon, 21 Sep 2015 12:50:40 +0000 (UTC)
 (envelope-from kraduk@gmail.com)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com
 [IPv6:2a00:1450:400c:c05::22c])
 (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 EB36710BE
 for <freebsd-fs@freebsd.org>; Mon, 21 Sep 2015 12:50:39 +0000 (UTC)
 (envelope-from kraduk@gmail.com)
Received: by wicge5 with SMTP id ge5so114418099wic.0
 for <freebsd-fs@freebsd.org>; Mon, 21 Sep 2015 05:50:38 -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=m7z16md8bpDtLiLy+PT7k2/yFze75ov6lBoSYBFxUoM=;
 b=jc07mhNPtbInT3Ux0YRvuiYMd1amsdCHnJlo9I+G9m2uSpqDxnABsSZoY6809zob1a
 kAB58nMvyctDZt6VB9awwxhHaRaT5e5757N0BgVBaBecQ26m2Rx9YHnbXd5jPucl6lqm
 GkUaQUu4BS0Zp8UQ+1sp2MJ6mX0SIhEjLBV2GDRpa0c71ki1UkOlzsKzNe50ZxZuhQDA
 nO0TNvTS/O60JTJOwQ1hQ1c5U4AtsJcfduheNIIm8QZmU7dJNI7n3BHfVfCTHUmKKgz9
 fZ+n+waHT658/Fd0eNJ/ApGgc262Nom5wfmqt5JyM8N8o8MVvTY/YvQeI7XqA0dtI/Il
 JjKQ==
MIME-Version: 1.0
X-Received: by 10.194.171.3 with SMTP id aq3mr23188952wjc.54.1442839838252;
 Mon, 21 Sep 2015 05:50:38 -0700 (PDT)
Received: by 10.28.125.18 with HTTP; Mon, 21 Sep 2015 05:50:38 -0700 (PDT)
In-Reply-To: <55FD9A2B.8060207@sneakertech.com>
References: <CAEW+ogbPswfOWQzbwNZR5qyMrCEfrcSP4Q7+y4zuKVVD=KNuUA@mail.gmail.com>
 <55FD9A2B.8060207@sneakertech.com>
Date: Mon, 21 Sep 2015 13:50:38 +0100
Message-ID: <CALfReyc1DcNaRjhhhx+4swF2hbfuAd2tWv2xpjWtfqcDoxHUBw@mail.gmail.com>
Subject: Re: ZFS cpu requirements, with/out compression and/or dedup
From: krad <kraduk@gmail.com>
To: Quartz <quartz@sneakertech.com>
Cc: FreeBSD FS <freebsd-fs@freebsd.org>
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 <freebsd-fs.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs/>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2015 12:50:40 -0000

"It's also 'permanent' in the sense that you have to turn it on with the
> creation of a dataset and can't disable it without nuking said dataset. "


This is completely untrue,  there performance issues with dedup are limited
to writes only, as it needs to check the DDT table for every write to the
file system with dedup enabled. Once the data is on the disk there is no
overhead, and in many cases a performance boost as less data on the disk
means less head movement and its also more likely to be in any available
caches. If the write performance does become an issue you can turn it off
on that particular file system. This may cause you to no longer have enough
capacity on the pool, but then pools are easily extended.