Samba login

[Jeremy Allison]

On Fri, Nov 03, 2000 at 05:37:01PM +0900, okuyamak at dd.iij4u.or.jp wrote:
> >>>>> "JA" == Jeremy Allison <jeremy at valinux.com> writes:
> JA> Have you taken a look at the re-design of the number
> JA> of stat calls for the Miami conference ? This should
> JA> help - the reason we have to do a stat call on an incoming
> JA> path is that we have to map the case insensitive name given
> JA> to smbd to a case sensitive name used by UNIX.
> 
> The following are what I could find easily:
> 
> ./source/lib/charset.c:load_client_codepage()
>   calls sys_stat() then calls open() without any change on
> 'codepage_file_name'.
> 
> ./source/lib/smbrun.c: setup_stdout_file()
>   calls sys_stat() then calls open() without any change in 'outfile'.
> 
> ./source/ilb/util_unistr.c: load_unicode_map()
>   calls sys_stat() then calls open() without any change on
> 'unicode_map_file_name'.
> 
> 
> I need to take more time, to find others.

Ok - but to be honest these calls are not a performance
problem. load_client_codepage() and load_unicode_map()
are done once on startup - I simply don't really care that
much about the efficiency of these functions.

The smbrun.c call is also not performance critical as at
this point smbd is preparing to fork and exec another
process - not the swiftest of tasks and also something
that is done quite rarely.

Now extra stat calls that can be removed in the main
smbd processing of client calls - they are worth optimizing.

Andrew's position is that the two things a kernel could
do to help Samba efficiency are (a) provide a readdir()
call that also returns stat information (as we are *always*
going to do a stat once we've done a readdir()) and (b)
a case insensitive filename lookup setting.

Note that we must do a stat or similar call before doing an
smb open as part of the return flags tell the client if the
file was created as a result of this operation - there is
no way to do that without doing a stat before the open (and
yes I know this is a race condition if done in user space,
there's nothing we can do about that).

>     transfer_file(0,smbd_server_fd(),(SMB_OFF_T)0,header,4,0);
> kind of codes.
> 
> If you check carefully about parameter of transfer_file(), first
> parameter '0' was file descriptor, and not something of simple
> index, length, or NULL ( yes, there's lots of place where 0 is being
> used instead of NULL ).
> 
> These 'direct number' also prevent many programmers from
> understanding. And you can find many, in Samba code.

I try and fix these whenever they are pointed out (note
the changes I put into later 2.0.x releases that replace
such "magic" numbers with flags like FILE_EXISTS_FAIL).

> It's "Interface between units" that's causing hard to tune. Not
> simply individual units. And because of this Interface unclearness,
> fix to them is being hard, especially when code is changing.
> 
> I think we should first face this fact.

Yes, but you also have to remember that a lot of what
Samba has to do is quite complex, simply because it is
emulating a complex system (NT Server) which has many
legacy rules we have to obey.

Having said that your comments are very accurate and
well received. I would prefer you run a profiler on
smbd and then let's concentrate on the code paths that
suck up most of the time (that's what I've been doing
with Herb in SGI's lab).

Cheers,

		Jeremy.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------