Parameterizing things in local.h

[Jeremy Allison]

Andrew Tridgell wrote:

> yeah, but just upping MAX_OPEN_FILES (whether at runtime or compile
> time) doesn't actually solve the problem. Many unixes have quite low
> limits on the total number of file descriptors. If you run 3 or 4
> clients each opening 1000 files then the global limit is reached and
> smbd will fail. We have to have a way to "idle" file descriptors to
> avoid the low limits that many unix systems have.

Yes, but this runs into the oplock problem. We need
to keep files open that are oplocked to have any
*hope* of maintaining file consistancy when the
commercial UNIX vendors (finally) add kernel level 
oplock support (which I believe they will when MS has
kicked them enough to be *really* scared - not
just mildly scared like they are now). Of course
Linux & FreeBSD will add it when we finally get
motivated enough to code it ourselves :-).

That's why I don't like the idling file descriptors
idea.

UNIX's that have a system wide limit of 4000
file descriptors are broken - most modern UNIX's
(those that run Apache at any rate) have 4096
fd's per *process*.

We would have the same situation as we do now
with the fast/slow share mode stuff. Those UNIX's
that implement the modern features get the
benefits - we just don't perform as well on
the older UNIX's - they won't be able to open
as many files.

I really don't want to lose chance of oplock consistancy
by implementing fd idling - there's just no way back 
from there once that code gets written and widely used. 
As a counterpoint, I don't think any other server does 
fd idling (at least I can't think of any).

Very few processes ever *use* that many fd's so
keeping the open files as real UNIX fd's doesn't
get to be that much of a drain on kernel resources,
it's just that those processes that *do* need them
transiently should be allowed to get them, without
having to re-compile Samba to achieve it.

Jeremy.