Date: Thu, 12 Jan 1995 10:29:21 +1100 From: Bruce Evans <bde@zeta.org.au> To: hackers@FreeBSD.org, roberto@blaise.ibp.fr Subject: Re: Meaning of maxfiles Message-ID: <199501112329.KAA23191@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>Has the meaning of maxfiles been changed somewhere ? I think so. It used to mean the system-wide limit, and still does in falloc() (grep for ENFILE). It is also used as a per-process limit grep for maxfiles and for RLIMIT_NOFILE) but I think this is just a quick fix for the per-process array of open files becoming too large. The vm changes apparently changed the meaning of maxfiles without changing its name (it should be renamed to something like maxfdesc) and missed the nfiles check in falloc()). Perhaps the nfiles check can just be deleted. If there has to be a system-wide limit, then the desiredvnodes limit in getnewvnode() should do. (desiredvnodes and nbuf seem to be too-small limits - 10 and 41 times smaller than I wanted and used for 1.1.5.) >config file follows, I added >options "CHILD_MAX=128" >options "OPEN_MAX=128" >When I ran out of processes... a while ago (duriing my 1.1.5 to 2.1 >change). Don't do this. OPEN_MAX should only be defined if the per-process limit is fixed. It is abused in the kernel to specify the current per-process limit. Libraries and user programs aren't compiled with option OPEN_MAX=128, so they see the bogus fixed OPEN_MAX of 64 instead of the bogus fixed OPEN_MAX of 128. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501112329.KAA23191>