ksmbd

[Guy Sotomayor]

Hi,

I've been a lurker on this list for a while now.  After Luke described his
architectural split and discussing some things, he suggested that I let the
rest of you in on what I've been doing.

I've been working on an in-kernel version of smbd for linux.  It contains
no samba code itself but does rely on things like nmbd for proper
operation.  Before everyone gets too bent out of shape, the design is not
too different from the knfsd server in linux that handles NFS requests.

Here's a basic overview of the architecture:

The server itself (the part that listens and communicates on port 139) is
a loadable kernel module.  When it receives something that is hard to
handle in the kernel (like user authentication) it passes it off to a user
space "helper" daemon (now you see why I'm interested in Luke's
architectural changes for msrpc).

The kernel server is multithreaded.  Each thread maintains an identity to
a user/session only while it is processing a request.  So all threads are
equal when they're idle.  All state about connections is done in look-aside
data structures.  Having a thread "become" a user takes about 5 stores (and
that can be made less)!  The look-aside data structures take 200-300 bytes
per session, < 100 per open file, and about 20 for each open file handle.
So the overhead for server operation is low, leaving lots of memory for
buffer cache.  Typically there would be 10-20 server threads.

There is no select().  It registers with the TCP stack so when a packet
arrives on port 139 one of the ksmbd threads is awakened and it starts
processing it.  The thread figures out which session/user the packet is
for by matching the kernel socket data structure with the look-aside
structures.  This is especially easy since there is an opaque (to the
socket) value that can be stored in the socket data structure.

I also take advantage of linux's dcache which allows portions of the
directory hierarchy (ie root of a share) to be pre-looked up.  This
allows all file lookups in ksmbd be relative to some base.  Since the
kernel path lookups are relative to a dcache entry this saves time.

Also by being in the kernel some of the data copies are eliminated so the
thing can really fly.  I don't have recent performance information since
I had to stop working on the project about 6 months ago to get a product
out.  Since the product is nearly out (well we announced a Comdex) I'm
about to start work on this again.

BTW the project is a Network Attached Storage server that runs linux
on a custom Power PC board -- 750 (aka G3), 1MB L2, upto 512MB ram,
2 LVD SCSI (80MB/sec each) channels, 2 10/100 ethernets all in the
size of a CDROM drive - oh and it all boots from flash -- look ma no
disks!

TTFN - Guy