Date: Fri, 29 Nov 1996 04:08:24 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: thorpej@nas.nasa.gov Cc: freebsd-bugs@freefall.freebsd.org Subject: Re: kern/2121: MAXBSIZE in param.h causes kernel panic if MSDOSFS LKM loaded Message-ID: <199611290908.EAA02006@dyson.iquest.net> In-Reply-To: <199611290850.AAA09258@freefall.freebsd.org> from "Jason Thorpe" at Nov 29, 96 00:50:02 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > The following reply was made to PR kern/2121; it has been noted by GNATS. > > From: Jason Thorpe <thorpej@nas.nasa.gov> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611290908.EAA02006>