[issue1726] tmpfs "malloc limit exceeded" panic

Venkatesh Srinivas (via DragonFly issue tracker) sinknull at leaf.dragonflybsd.org
Fri Sep 10 06:51:16 PDT 2010


Venkatesh Srinivas <me at acm.jhu.edu> added the comment:

thomas - the deep namecache recursions 'should' be happening on shutdown 
(actually unmount); they are a real problem - a full tmpfs (by nodes) on a 
system with 1.5GB of RAM takes upwards of 5 min to unmount. Why the ncp->nc_name 
field is empty I don't know either....

status:
- tmpfs should survive fsstress at the minute
- >1 tmpfs will be a problem, the name zone is shared
- there are workloads which will still panic it...
- unmount after fsstress takes a long time

stuff to do still standing:
- Move the tmpfs name zone from a global malloc zone to a per-mount zone
- Convert dirent allocations from M_WAITOK to M_WAITOK | M_NULLOK and handle 
the null return case; there are only two places that dirents are allocated, so 
this wouldn't be too bad.
- Figure out why the unmount is hitting so many namecache entries with null 
names
- Write a link stress test (something that makes a _lot_ of links) to see if we 
can exhaust the dirent zone currently.

----------
status: testing -> in-progress

_____________________________________________________
DragonFly issue tracker <bugs at lists.dragonflybsd.org>
<http://bugs.dragonflybsd.org/issue1726>
_____________________________________________________






More information about the Bugs mailing list