From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 09:07:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18E791065672 for ; Mon, 15 Feb 2010 09:07:58 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 024588FC13 for ; Mon, 15 Feb 2010 09:07:57 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta06.emeryville.ca.mail.comcast.net with comcast id i94G1d0011afHeLA697ytl; Mon, 15 Feb 2010 09:07:58 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta17.emeryville.ca.mail.comcast.net with comcast id i97x1d0033S48mS8d97xkB; Mon, 15 Feb 2010 09:07:57 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 59DE01E301A; Mon, 15 Feb 2010 01:07:56 -0800 (PST) Date: Mon, 15 Feb 2010 01:07:56 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100215090756.GA54764@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 09:07:58 -0000 On Mon, Feb 15, 2010 at 10:49:47AM +0200, Dan Naumov wrote: > > I had a feeling someone would bring up L2ARC/cache devices. This gives > > me the opportunity to ask something that's been on my mind for quite > > some time now: > > > > Aside from the capacity different (e.g. 40GB vs. 1GB), is there a > > benefit to using a dedicated RAM disk (e.g. md(4)) to a pool for > > L2ARC/cache? The ZFS documentation explicitly states that cache > > device content is considered volatile. > > Using a ramdisk as an L2ARC vdev doesn't make any sense at all. If you > have RAM to spare, it should be used by regular ARC. ...except that it's already been proven on FreeBSD that the ARC getting out of control can cause kernel panics[1], horrible performance until ZFS has had its active/inactive lists flushed[2], and brings into question how proper tuning is to be established and what the effects are on the rest of the system[3]. There are still reports of people disabling ZIL "for stability reasons" as well. My thought process basically involves "getting rid" of the ARC and using L2ARC entirely, given that it provides more control/containment which cannot be achieved on FreeBSD (see above). In English: I'd trust a whole series of md(4) disks (with sizes that I choose) over something "variable/dynamic" which cannot be controlled or managed effectively. The "Internals" section of Brendan Gregg's blog[4] outlines where the L2ARC sits in the scheme of things, or if the ARC could essentially be disabled by setting the minimum size to something very small (a few megabytes) and instead using L2ARC which is manageable. [1]: http://lists.freebsd.org/pipermail/freebsd-questions/2010-January/211009.html [2]: http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/053949.html [3]: http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055073.html [4]: http://blogs.sun.com/brendan/entry/test -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |