From owner-freebsd-fs@FreeBSD.ORG Tue Nov 20 13:08:00 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 62CD77E7 for ; Tue, 20 Nov 2012 13:08:00 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id ABCDA8FC0C for ; Tue, 20 Nov 2012 13:07:59 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.5/8.14.5) with ESMTP id qAKCgjnt028008 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 20 Nov 2012 14:42:46 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <50AB7AC5.3020700@digsys.bg> Date: Tue, 20 Nov 2012 14:42:45 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.10) Gecko/20121029 Thunderbird/10.0.10 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> <50A64694.5030001@egr.msu.edu> <20121117181803.GA26421@neutralgood.org> <20121117225851.GJ1462@egr.msu.edu> <20121120040258.GA27849@neutralgood.org> In-Reply-To: <20121120040258.GA27849@neutralgood.org> 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: Tue, 20 Nov 2012 13:08:00 -0000 On 20.11.12 06:02, kpneal@pobox.com wrote: > Advising people to use dedup when high dedup ratios are expected, and > advising people to otherwise not use dedup, is by itself incorrect > advice. Rather, dedup should only be enabled on a system with a large > amount of memory. The usual advice of 1G of ram per 1TB of disk is > flat out wrong. Perhaps, increasing vfs.zfs.arc_meta_limit is appropriate. It's the starvation for metadata that trashes both memory and disks. By default, that tunable is set to 1/4 of the ARC size. Perhaps 2/3 or even up to the ARC size is better. Changed in /boot/loader.conf. Just an idea, I haven't yet tested this, but from time to time do observe memory starvation from dedupe. (test pending the resilver of an 30TB array, which is abysmally slow) Daniel