From owner-freebsd-bugs Fri Nov 29 01:08:39 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA10333 for bugs-outgoing; Fri, 29 Nov 1996 01:08:39 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA10326 for ; Fri, 29 Nov 1996 01:08:35 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id EAA02006; Fri, 29 Nov 1996 04:08:24 -0500 (EST) From: "John S. Dyson" Message-Id: <199611290908.EAA02006@dyson.iquest.net> Subject: Re: kern/2121: MAXBSIZE in param.h causes kernel panic if MSDOSFS LKM loaded To: thorpej@nas.nasa.gov Date: Fri, 29 Nov 1996 04:08:24 -0500 (EST) Cc: freebsd-bugs@freefall.freebsd.org In-Reply-To: <199611290850.AAA09258@freefall.freebsd.org> from "Jason Thorpe" at Nov 29, 96 00:50:02 am X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The following reply was made to PR kern/2121; it has been noted by GNATS. > > From: Jason Thorpe > To: jehamby@lightside.com > Cc: FreeBSD-gnats-submit@freebsd.org > Subject: Re: kern/2121: MAXBSIZE in param.h causes kernel panic if MSDOSFS LKM loaded > Date: Fri, 29 Nov 1996 00:37:26 -0800 > > On Thu, 28 Nov 1996 23:53:12 -0800 (PST) > jehamby@lightside.com wrote: > > > sys/param.h was recently changed to define MAXBSIZE as 32768 if MSDOSFS is > > defined, or 16384 otherwise. If MSDOSFS is not compiled into the kernel, > > but instead loaded as an LKM (as I have done), then the kernel immediately > > panics with: "panic: getblk: size(32768) > MAXBSIZE(16384)" when the LKM > > is loaded. > > MAXBSIZE should probably just expand to MAXPHYS. It seems seriously > wrong to conditionalize it on some random config option. > It is also seriously wrong to take up to 128MB of kernel space for the buffer cache (we can support arbitrary amounts of KVA space, but it is ugly just to throw it away.) The problem is more complex than "just doing it." We have large server systems to consider also. There will be a solution soon, but I don't want to just hack one out. There are alot of variables to consider including off the top: We want to support a nice number of buffers We want to support MSDOSFS (soon to be a new one.) We don't want the buffers to take much of the kernel virtual space. The buffers have fixed kva space allocated to them. A dynamic scheme is slower, and likely to deadlock or fragment unless carefully considered. Using large amounts of kva space has negative consequences on performance. These are only some of the variables that I am working with. The short term fix is for the individual with the problem to bump up the parameter (as long as he is running on a small system.) Other users with the problem previously will also get panics instead of corruption, but we will at least get the input (and people will be keeping their filesystems.) For the dynamic scheme, I might resurrect a concept that I had developed about 3-4yrs ago when working on the initial dynamic/merged buffer cache code. Thinking this stuff through takes time though. At least we caught a nasty one now!!! John