Pushing Samba functions into the kernel

[Richard Sharpe]

On Thu, 13 Feb 2003, Steven French wrote:

> >jra wrote
> >
> >Ok, my feelings on "Samba in the kernel" are the following.
> >
> >1). We need to be able to de-multiplex incoming SMB's at the kernel
> >level to get over the W2K Terminal Server problem.
> >2). A utf8 case-insensitive filesystem (massive performance win).
> >3). Implement SMBreadX/SMBwriteX in the kernel once a channel has
> >been set up.
> >4). Allow NT SD's stored in EA's to be interpreted by security
> >code living in the kernel for open decisions.
> >
> >Everything else (IMHO) is better done in user space.
> 
> That is reasonably sensible, although the dirlookup may not be required to
> be in kernel to take advantage of the particular issue of case-insensitive
> file compares - if you are willing to live with case preserving/case
> insensitive behavior for local apps too for a particular partition - jfs
> allows formatting partitions case-insensitive (and it is probably doable in
> others with more work).   Optimizing the Unicode string
> comparisons/conversions would be a huge performance win and worth looking
> at inkernel findfirst/findnext.

OK, we don't care about local apps at all, being a NAS, and I suspect that 
a lot of others who are interested in this discussion don't care either. 
However, we do care about NFS clients and CIFS clients sharing the same 
storage space, and even though there is often little actual shared file 
access going on, we still want to serve both sets of clients from the one 
underlying file system.

Have a look at Tridge's presentation on this issue.

> The new kernel nanosecond timestamps can probably be accessed in userspace
> without requiring in kernel - but that feature was a nice recent addition
> to the kernel. 

Well, the API for accessing 64-bit time stamps on files is not clear :-)

>                   Hooking in the kernel socket layer more sensibly for
> scatter/gather like operations for SMB read/write to take advantage of TOEs
> will be a big win.   There is plenty of precedent for doing a subset of SMB
> ops in kernels, and throwing the rest to user space.   The addition of LSM
> makes some very interesting authorization behaviors possible but is a
> distinct in-kernel piece.    The addition of the well known xattr name for
> the 32 bit quantity system.dosattributes (in addition to the two existing
> well defined xattrs "system.defaultacl" etc.) would be helpful - probably
> something I should submit to the lkml - the xattr is transparent to
> everyone but cifs, smbfs and ntfs (only a few apps like backup apps and
> Samba would care)

OK, so some of us are thinking of similar things. What I would like to 
progress to is some discussion around the sort of changes that would be 
needed to allow this to be easily done.

Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, 
sharpe[at]ethereal.com, http://www.richardsharpe.com