Date: Tue, 29 Jul 2003 17:42:04 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Dave Dolson <ddolson@sandvine.com> Cc: "'freebsd-stable@freebsd.org'" <freebsd-stable@freebsd.org> Subject: RE: kernel deadlock Message-ID: <Pine.NEB.3.96L.1030729174019.78063E-100000@fledge.watson.org> In-Reply-To: <FE045D4D9F7AED4CBFF1B3B813C853370191903A@mail.sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 29 Jul 2003, Dave Dolson wrote: > To follow up, I've discovered that the system has exhausted its "FFS > node" malloc type. > > >From vmstat on the core file, the "FFS node" MALLOC type is full: > > > Memory statistics by type Type Kern > Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) > ... > FFS node409600102400K 102400K102400K 1138048 3 0 256 > ... > > The stress test is recursively creating a directory then cd'ing to it, > trying to create 1,000,000 deep. > > You might say "don't do that", but this doesn't require any special > priviledge, so is a potential DoS attack by any user. > > I'm wondering why the MALLOC is done with M_WAITOK; it seems like > something which could reasonably fail. > > Or, why aren't the cached inodes being purged? Some problems with this have turned up in -CURRENT on large-memory machines where some of the scaling factors have been off. In -CURRENT, I believe changes were introduced to bound the number of active vnodes more rigorously at large memory sizes, and they probably need to be merged to -STABLE. You may want to try lowering the value of kern.maxvnodes during the boot process -- however, the number of vnodes can exceed this max under a number of common circumstances, so that may not be sufficient (worth a try). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030729174019.78063E-100000>