From owner-freebsd-fs@FreeBSD.ORG Fri Nov 16 14:04:59 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89464DE4 for ; Fri, 16 Nov 2012 14:04:59 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mail.egr.msu.edu (hill.egr.msu.edu [35.9.37.162]) by mx1.freebsd.org (Postfix) with ESMTP id 563D78FC0C for ; Fri, 16 Nov 2012 14:04:58 +0000 (UTC) Received: from hill (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 0D4802F1E7 for ; Fri, 16 Nov 2012 08:58:45 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by hill (hill.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zU1ZlQZAaNSx for ; Fri, 16 Nov 2012 08:58:44 -0500 (EST) Received: from EGR authenticated sender Message-ID: <50A64694.5030001@egr.msu.edu> Date: Fri, 16 Nov 2012 08:58:44 -0500 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121115 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: SSD recommendations for ZFS cache/log References: <57ac1f$gf3rkl@ipmail05.adl6.internode.on.net> <50A31D48.3000700@shatow.net> <20121116044055.GA47859@neutralgood.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 14:04:59 -0000 On 11/16/12 00:41, Zaphod Beeblebrox wrote: > On Thu, Nov 15, 2012 at 11:40 PM, wrote: >>> + >>> + The answer very much depends on the expected workload. >>> + Deduplication takes up a signifigent amount of RAM and CPU >>> + time and may slow down read and write disk access times. >>> + Unless one is storing data that is very heavily >>> + duplicated (such as virtual machine images, or user >>> + backups) it is likely that deduplication will do more harm >>> + than good. Another consideration is the inability to >> >> I advise against advice that is this firm. The statement that it will "do >> more harm than good" really should be omitted. And I'm not sure it is >> fair to say it takes a bunch of CPU. Lots of memory, yes, but lots of >> CPU isn't so clear. > > I experimented by enabling DEDUP on a RAID-Z1 pool containing 4x 2T > green drives. The system had 8G of RAM and was otherwise quiet. I > copied a dataset of about 1T of random stuff onto the array and then > copied the same set of data onto the array a second time. The end > result is a dedup ration of almost 2.0 and only around 1T of disk > used. > > As I recall (and it's been 6-ish months since I did this), the 2nd > write became largely CPU bound with little disk activity. As far as I > could tell, the dedup table never thrashed on the disk ... and that > most of the disk activity seemed to be creating the directory tree or > reading the disk to do the verify step of dedup. > > The CPU is modest... a 2.6 Ghz Core-2-duo --- and I don't recall if it > busied both cores or just one. > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > Now try deleting some data and the fun begins :)