From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 09:50:10 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 E2EBC1065670 for ; Mon, 15 Feb 2010 09:50:10 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8AAA78FC14 for ; Mon, 15 Feb 2010 09:50:10 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2C3B6.dip.t-dialin.net [217.226.195.182]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 6AFE8844F3D; Mon, 15 Feb 2010 10:50:04 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 09EB1CD82F; Mon, 15 Feb 2010 10:50:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1266227401; bh=dnUpk/RhCDiCIN+5cdZSuhrOey5sgjYHb3Iezemfzr4=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=O7d7zMQbHUODXgQG6Drtt4OriznttzYovbIm8XyyQsI43YVxSWU7dRqmmXrV7kPFo WwtmsZ/B9jaHy50Pc3S+am/sNi15RLGEhwyjSOti2i2iX5CEGoYjJh7tNlEMP4ewDa Y7QEMgVlYjCfA5dnq8m2W6hKC06U4r00KI/5AaEMnd8zun9ZUGD+7v0aEMwXMvEmQ5 pnHmeRzjyxVdRVXFGuQuL4/eGhnUBvsPGPIKWcnLWvcR2KGGQl+iZlBaBTCdizyUjK 47EMzPU3GTrV+bMClMYsRv+nopG1MUJmh8W3Dm8Gkkhur4ipizyKr8RFvonYSaHO0s +NQnDZQfod/eA== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id o1F9o0mJ086320; Mon, 15 Feb 2010 10:50:00 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Mon, 15 Feb 2010 10:50:00 +0100 Message-ID: <20100215105000.101326yj01j0f64g@webmail.leidinger.net> Date: Mon, 15 Feb 2010 10:50:00 +0100 From: Alexander Leidinger To: Jeremy Chadwick References: <20100215090756.GA54764@icarus.home.lan> In-Reply-To: <20100215090756.GA54764@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 6AFE8844F3D.7B35B X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.44, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1266832205.52346@38gYt3GKTDHcOWUhybIiXw X-EBL-Spam-Status: No Cc: freebsd-stable@freebsd.org 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:50:11 -0000 Quoting Jeremy Chadwick (from Mon, 15 Feb 2010 01:07:56 -0800): > 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 There are other ways (not related to ZFS) to shoot into your feet too, I'm tempted to say that this is a) a documentation bug and b) a lack of sanity checking of the values... anyone out there with a good algorithm for something like this? Normally you do some testing with the values you use, so once you resolved the issues, the system should be stable. > ZFS has had its active/inactive lists flushed[2], and brings into Someone needs to sit down and play a little bit with ways to tell the ARC that there is free memory. The mail you reference already tells that the inactive/cached lists should maybe taken into account too (I didn't had a look at this part of the ZFS code). > 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 That's what I talk about regarding b) above. If you specify an arc_max which is too big (arc_max > kmem_size - SOME_SAVE_VALUE), there should be a message from the kernel and the value should be adjusted to a save amount. Until the problems are fixed, a MD for L2ARC may be a viable alternative (if you have enough mem to give for this). Feel free to provide benchmark numbers, but in general I see this just as a workaround for the current issues. > disabling ZIL "for stability reasons" as well. For the ZIL you definitively do not want to have a MD. If you do not specify a log vdev for the pool, the ZIL will be written somewhere on the disks of the pool. When the data hits the ZIL, it has to be really on a non-volatile storage. If you lose the ZIL, you lose data. > 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. At least in 7-stable, 8-stable and 9-current, the arc_max now really corresponds to a max value, so it is more of providing a save arc_max than a minimal arc_max. No matter how you construct the L2ARC, ARC access will be faster than L2ARC access. > [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 Bye, Alexander. -- BOFH excuse #439: Hot Java has gone cold http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137