kern/53350: fill up a malloc md-disk on 5.1-R causes panic

[Jason Kuri]

The following reply was made to PR kern/53350; it has been noted by GNATS.

From: Jason Kuri <jay at oneway.com>
To: "Poul-Henning Kamp" <phk at phk.freebsd.dk>
Cc: FreeBSD-gnats-submit at freebsd.org
Subject: Re: kern/53350: fill up a malloc md-disk on 5.1-R causes panic 
Date: Sun, 15 Jun 2003 11:51:39 -0500

 Ok, so speaking practically, how do I deal with this issue?  I have a 
 script that needs to be able to cache directories in ram...  As I said, 
 I was able to do this as recently as April 30.  Is there some sort of 
 tunable parameter I can use to increase kernel's malloc bucket limit?  
 (kernel option or ..?  )  Or, at absolute least, some way to determine 
 what it is, so that I can force the script not to use more than that?   
 and how much must be free leftover to allow the system to run 
 'normally' ?
 
 Shouldn't mdconfig not allow me to reserve more space than it can 
 provide me with?  I'm not '-o force'ing the mdconfig.  It seems to me 
 that if the request is for too much, the mdconfig should fail.
 
 and still if it is too much, shouldn't it deny the allocation rather 
 than panic?   It seems to me like the amount that the system can 
 provide changes between the time I mdconfig the disk, and the time I 
 try to use it.
 
 Thanks for your assistance,
 
 Jay
 
 On Sunday, June 15, 2003, at 11:35  AM, Poul-Henning Kamp wrote:
 
 > In message <FC408487-9F4E-11D7-B102-00039398BAE0 at oneway.com>, Jason 
 > Kuri writes
 > :
 >> Hi there,
 >>
 >> That makes sense... but hold on a sec.
 >>
 >> I have 256M of ram, and try to use 110M for malloc-disk, and my 
 >> machine
 >> panics?  That seems awfully broken to me.
 >
 > Notice I said "Kernel mapped memory".
 >
 > That's usually on the order of 1/3 or your RAM.
 >
 > -- 
 > Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
 > phk at FreeBSD.ORG         | TCP/IP since RFC 956
 > FreeBSD committer       | BSD since 4.3-tahoe
 > Never attribute to malice what can adequately be explained by 
 > incompetence.
 >