Samba login

[Jeremy Allison]

On Fri, Nov 03, 2000 at 03:34:48AM +0900, okuyamak at dd.iij4u.or.jp wrote:

> In most case, stat() can be replaced with fstat(), for usually,
> after you call stat() and make sure that file exists, you'll call
> open(). Both stat() and open() requires 'filename->i-node'
> conversion, which takes lots of time ( ex. 90% of stat() is used for
> filename->i-node conversion ). fstat() does not need this
> conversion, for file descriptor remembers i-node. And what's even
> more important is that:
>  i) open() can check existance of file just like stat().
> ii) very fact that you found file with stat() does not mean
>     file will exist even at open() timing. There are other process
>     who have chance of removing the file.
> and since so, stat()->open() sequence have no meaning. Correct
> answer is open()->fstat(). But since code is so messy, it's hard to
> find out which can be replaced and which cannot be.

Have you taken a look at the re-design of the number
of stat calls for the Miami conference ? This should
help - the reason we have to do a stat call on an incoming
path is that we have to map the case insensitive name given
to smbd to a case sensitive name used by UNIX.

ie. The client can pass \AN\UPPER\CASE\DIRECTORY\PATH
and expect it to match a similar UNIX path of any
case. The statcache code does this mapping by saving 
the longest matching path in a case sensitive way.
The incoming request does a stat to check if this
path is still valid (ie. The case insensitive mapping
is still valid). I don't see a good way to remove
this stat. Once the file has been opened I always
use fstat - but it would be difficult to change the
layering of the calls to have the first  inode lookup
done by the open - but maybe not impossible (you have
given me an idea here..... :-).

The change I made in Miami is to keep the results of
this first stat around and use it instead of doing
further stats (as we were doing). Can you take a look
at the new code in 2.2.0 and give an assessment please,
as you seem to be very good at this kind of work.

> If select() does not have to wait for pipe, select() can be removed
> and we only need to block-read(). This can be implemented by using
> interruption from IPC caller, but since SIG_USER1 and SIG_USER2 are
> both being used for debug purpose ( which I don't think is smart
> idea. using SIG_USER? for ANY communication with parent process, and
> using SIG_HUP for passing debugging flag to top smbd, is enough ),
> this can't be implemented without large change.

SIGUSR1 is now used for message passing. The USR1/2 debugging
code has now been removed.

> As you can see, you can think of many ways to reduce cpu power, but
> none of them can be done easily. It'll be impossible especially when
> major development team focus on adding new functionality, for
> shooting moving target is lot harder than to shood stopping target.
> Current Samba's implementation is not designed well so that lower
> communication layer is devided from upper functionality layer too.
> # And if you take look at code more carefully, you'll find
> # many bugs in non-major path, which also will cause unstability.

Specifics please ! This is how we get things fixed. I know
you've been sending in bug fixes and I've been integrating
them as fast as I get them - thanks. If you know of more
bugs please pass them along to us.

> Stop developing Samba-2.2, and focus on re-designing.  What we first
> need is Samba-2.0.8, with totally new lower communication layer.
> After we made stable, robust, and fast lower communication layer,
> it'll be lot easier to make more function above it.

Well, the 2.2 code structure is actually *cleaner*
than the 2.0.x codebase (IMHO - and Andrew's I think).

Most of the new functionality is being added in the RPC
code which is completely orthoganal to the network
layer and stat work you are describing here.

I'd like to be able to improve the network layer code,
and reduce the stat calls whilst also adding in the
RPC functionality that people need.

I'm very impressed with your work - let me know what
else we can do to help !

Thanks,

		Jeremy Allison,
		Samba Team.

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