Parameterizing things in local.h

[Andrew Tridgell]

Jeremy wrote:
> 	I've been doing some thinking about local.h,
> and I was wondering why we don't just parameterize
> things such as MAX_OPEN_FILES, MAX_CONNECTIONS,
> MAXSTATUS, MAXDIR, and (horror of horrors :-)
> GUEST_SESSSETUP.

some of them, yes.

It makes sense to parameterize MAX_OPEN_FILES. The others don't matter
nearly as much.

Here's why:

MAXSTATUS: This could actually get removed completely. It was only
	there because when I first wrote the status code I was afraid
	that it might have a runaway bug. No bug has shwon up :)
	Crrently MAXSTATUS is 100000 which is way larger than any
	system can handle but we could just as easily remove the check
	completely as the code already handles arbitrary sizes.

MAX_CONNECTIONS: This is the maximum number of tree connection
	structures per socket. To exceed it a single PC would have to
	mount 128 different shares simultanously from one server. We
	could fix this and remove the restriction completely but it
	may not be worth the effort as I've never heard of anyone ever
	getting even close to that limit.

MAXDIR: That could be parameterized. Note that MAXDIR does not limit
	the number of open directories, it is merely a server-internal
	tuning optimization that limits the number of active
	directories. When the limit is exceeded the less active
	directories are internally idled. As far as the client is
	concerned the number of open directories is unlimited (well,
	it's actually limited to 2^16 as the fd field in the protocol
	is 16 bits)

GUEST_SESSSETUP: I'm loath to parameterize that one for reasons I've
	ranted about before. We will be gaining some functionality in
	exchange for periodic and very hard to track down errors
	caused by the broken MS handling of re-connects. MS don't seem
	to want to fix this so allowing people to set GUEST_SESSSETUP
	will just cause major headaches (just getting people to
	understand _why_ they shouldn't set this option is a major
	undertaking.)

The main one we want to do is MAX_OPEN_FILES. The current limit is
just silly. We really want a different data structure and the ability
to idle files. I've discussed this before but I haven't actually
gotten around to doing anything about it.

Maybe the best/easiest solution is to leave the data structure alone
and just add file idling (like we added to directories). That way
MAX_OPEN_FILES becomes an internal optimisation thing just like MAXDIR
and the client will see an infinite limit (well, 2^16 anyway ... damn
16 bit protocol).

The trickiest bit of this is that we will have to index the Files[]
array with a different thing to what we send over the wire. Shouldn't
be too hard ...

> We could just malloc the space on startup - once
> we've read the smb.conf, and thus get rid of many
> annoying restrictions at once (I started along
> this line after reading about a successful
> Samba vs NT benchmark by an integrator in an
> Inforworld forum - he needed to increase
> MAX_OPEN_FILES and recompile - it made me
> realize if he had been less technically savvy
> we would have lost there....).

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.

Cheers, Andrew