From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 01:30:37 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A182A16A408; Tue, 10 Apr 2007 01:30:37 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 83B2913C4C3; Tue, 10 Apr 2007 01:30:37 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id 37CE7110C5; Mon, 9 Apr 2007 20:30:37 -0500 (CDT) Date: Mon, 9 Apr 2007 20:30:35 -0500 From: Craig Boston To: Kris Kennaway Message-ID: <20070410013034.GC8189@nowhere> Mail-Followup-To: Craig Boston , Kris Kennaway , freebsd-current@FreeBSD.org, Pawel Jakub Dawidek , freebsd-fs@FreeBSD.org References: <20070407025644.GC8831@cicely12.cicely.de> <20070407131353.GE63916@garage.freebsd.pl> <4617A3A6.60804@kasimir.com> <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> <20070407191517.GN63916@garage.freebsd.pl> <20070407212413.GK8831@cicely12.cicely.de> <20070410003505.GA8189@nowhere> <20070410003837.GB8189@nowhere> <20070410011125.GB38535@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070410011125.GB38535@xor.obsecurity.org> User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2007 01:30:37 -0000 On Mon, Apr 09, 2007 at 09:11:25PM -0400, Kris Kennaway wrote: > Nah, you were right the first time :) Your system is defaulting to > 160MB for the kmem_map, of which zfs will (by default) try to use up > to 3/4. Naturally this doesn't leave much for the rest of the kernel > (40MB), so you'll easily run the kernel out of memory. Hmm, I had already reduced the maximum arc size to 64MB though, which I figured (hoped?) would leave plenty of room. So if kmem_size is the total size and it can't grow, what is kmem_size_max? Is there a way to see a sum of total kmem allocation? Even the vm.zone breakdown seems to be gone in current so apparently my knowledge of such things is becoming obsolete :) > For now, you probably want to increase vm.kmem_size a bit to allow > some more room for zfs, and set vfs.zfs.arc_max and arc_min to > something more reasonable like 64*1024*1024+1 (the +1 is needed > because zfs currently requires "greater than 64MB" for the arc). Yeah, I found that out the hard way after wondering why it was ignoring the tunables :) I ran out of kmem_map space once with it set to 64*1024*1024+1, then I modified the source so that it would accept zfs_arc_max >= (64 << 20) instead, just in case it was a power-of-2 thing. Craig