Parameterizing things in local.h

[Luke Kenneth Casson Leighton]

> 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 ...

if you're considering doing this, then may i recommend the NT data
structure which actually contains an index number already.  i have my
suspicions that the data structures passed out to SRVMGR.EXE via
NetrFileEnum at info level 3 are actually kernel-level structures. 

if it's good enough for NT, it's good enough for us :-)


#ifndef _RPC_SRVSVC_H /* _RPC_SRVSVC_H */
#define _RPC_SRVSVC_H 

....
....

/* FILE_INFO_3 (level 3 file info strings) */
typedef struct file_info3_info
{
	uint32 id;            /* file index */
	uint32 perms;         /* file permissions. don't know what format */
	uint32 num_locks;     /* file locks */
	uint32 ptr_path_name; /* file name */
	uint32 ptr_user_name; /* file owner */

} FILE_INFO_3;

/* FILE_INFO_3_STR (level 3 file info strings) */
typedef struct str_file_info3_info
{
	UNISTR2 uni_path_name; /* unicode string of file name */
	UNISTR2 uni_user_name; /* unicode string of file owner. */

} FILE_INFO_3_STR;

....
....

#endif /* _RPC_SRVSVC_H */


> > 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
>