Parameterizing things in local.h
Luke Kenneth Casson Leighton
lkcl at switchboard.net
Thu Apr 9 12:12:16 GMT 1998
> 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
>
More information about the samba-technical
mailing list