From owner-freebsd-fs@FreeBSD.ORG Wed May 23 18:19:06 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 4651F16A421; Wed, 23 May 2007 18:19:06 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 306F013C455; Wed, 23 May 2007 18:19:06 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 012F11A4D83; Wed, 23 May 2007 11:20:07 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3513C52EE3; Wed, 23 May 2007 14:19:05 -0400 (EDT) Date: Wed, 23 May 2007 14:19:04 -0400 From: Kris Kennaway To: Ivan Voras Message-ID: <20070523181903.GA60674@xor.obsecurity.org> References: <20070410003837.GB8189@nowhere> <20070410011125.GB38535@xor.obsecurity.org> <20070410013034.GC8189@nowhere> <20070410014233.GD8189@nowhere> <4651BD6F.5050301@unsane.co.uk> <20070522083112.GA5136@hub.freebsd.org> <4652B15D.5060505@unsane.co.uk> <20070523085532.GA27542@hub.freebsd.org> <20070523093231.GA29797@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2007 18:19:06 -0000 On Wed, May 23, 2007 at 12:11:52PM +0200, Ivan Voras wrote: > Kris Kennaway wrote: > > >i.e. plain ZFS wants to use 3/4 of the *physical* RAM in the system > >(or all but 1GB). i.e. if you have 16GB in your system then zfs will > >try to use up to 15GB of it for caching leaving only 1GB for > >everything else (kernel + userland). > > > >I would actually be interested to know how Solaris gets away with > >this. It sounds like there must be less of a distinction between > >memory allocated to the kernel and to userland, and the ability for > >memory to flow between these two with some form of backpressure when > >userland wants memory that is currently gobbled by up solaris ZFS. > > Isn't it adequately explained with Sparc being a 64-bit platform? Not entirely, because solaris also runs on i386 (this is what was confusing me). I guess the answer is that ZFS has similar issues on Solaris i386 that it did on FreeBSD i386. Kris