Proposed patch for Samba-2.0.7 to allow Solaris open more than 1014 (or rlim_fd_max) files

[Andy Polyakov]

> >Compiling with sfio doesn't solve all the problems. The remaining
> >problem is that we don't know if library functions called by SAMBA call
> >fopen and company. Linking with binary compatibility shim doesn't help
> >as it would presumably suffer from the very same deficiency (or won't be
> >binary compatible).
> 
> Please remember, as mentioned before, that this whole stdio/sfio/MAX_OPEN
> thing is a sidetrack from the real (setrlimit) discussion.

Sure we remember that, but it was the author of the original post who
brought the issue up:-)

> > > The reason for this is that smbd uses fopen 
> > > If an smbd process has > 256 files but < 1014
> > > (rlim_fd_max) files open it can still fail to open
> >
> >This is not 100% correct. It breaks when open(2) returns number larger
> >than 255, not when you have more than 256 files opened.
> 
> Since open(2) is guaranteed to always return the lowest available file
> descriptor, this is a distinction without a difference IMHO (aside from the
> 255/256 off-by-one error).

There is no off-by-one error. If you don't shuffle file descriptors,
open(2) returns 255 when you open 256th file, doesn't it? And there's a
distinction as you yourself realized when you examined the URL.

> >http://lists.samba.org/pipermail/samba-ntdom/1999-August/019940.html for
> >further information and a possible workaround.
> 
> ... any idea why it didn't get rolled in?

No. Probably because it was brought up as a side comment, just like this
time:-)

> Was it just
> overlooked or did someone have a problem with it?

Rather nobody (but me at that time) experienced a problem without it...
Indeed, it takes a site running Solaris (in some specific configuration
as it's most likely nss_*.so modules that use stdio and therefore would
suffer), pushing SAMBA hard on it and sticking to Solaris when a problem
arises. And there aren't many enough to care about...

> >I should also recommend -DUSE_POLL and -DFD_SETSIZE=2400 (or something),
> >-DUSE_POLL effectively prevents SAMBA from using select (which is btw
> >very similar front-end to poll anyway) and FD_SETSIZE scales up
> >structures used by SAMBA itself.
> 
> Do you mean HAVE_POLL?

No, I ment USE_POLL ... but in 2.0.x (that's what subject suggests as
well). See source/lib/system.c there.

> I don't see USE_POLL anywhere. This is in current CVS 2.2.

It probably should be put back then, preferably with properly scaled pfd
array:-)

Andy.