[Samba] Re: New maintainer needed for the Linux smb filesystem

[Steven French]

We are close, but not quite ready to disable smbfs.   At the annual cifs
plugfest and at connectathon (testing) cifs is doing well,  and better on
most functional, performance and stability tests at this point in mainline
than smbfs but there are a few cases in which smbfs is better that I have
not had time yet to address, but do expect to finish within four or five
months.   I am satisfied with cifs stability in current mainline, but there
are a steady stream of new functional requirements that are coming in and a
few posix features that require significant compensations (posix -> cifs
ACLs e.g.).   Getting near perfect posix semantics is not easy to Windows
is hard (easier to Samba of course) but we are getting closer.   The key
smbfs features that still need to be addressed:

1) Kerberos authentication:  CIFS does not upcall to kerberos/spnego libs
for session authentication which is a requirement for some, and a desirable
security feature.    This should be finished by November.   The missing
piece, the userspace samba 4 utility, misleading named in this case,
"ntlm_auth," easily could do the function but I have been putting off
putting an upcall into cifs (mostly because I have not seen an
implementation much better than the autofs or nfsv4 upcalls, and they
seemed awkward to me).   If anyone has a favorite upcall mechanism that is
better than the autofs's approach, I would like to know.

2) backlevel server support:   I need to run tests from cifs client against
Win9x and OS/2 to see how feasible adding support for mounting to those as
servers would be.   smbfs can probably still mount to those.

3) write performance - there are a few cases in which smbfs performance for
large writes is better than cifs due to cifs allocating larger buffers
which can lead to cifs putting memory pressure on the slab.    I have been
adding experimental code in cifs to fix this - by adding writepages to
increase the write size on the network significantly and to not allocate a
large buffer in the write path.

The first one is a showstopper for some customers.

I don't mind fixing any major smbfs bugs that are found as needed, the code
is not hard to follow, but I would rather focus on the three current cifs
priorities:

a) getting the upcall mechanism right for item 1 (and needed for cifs "dfs"
support)
b) improving the write performance and adding an async style dispatching
for readpages (perhaps by fixing up James Roper's patch)
c) finishing the merge of the cifs DNOTIFY support from the google summer
of code project

I have a relatively large number of cifs changesets (almost 20) in the cifs
development tree that I have been waiting for 2.6.13 before I offer them to
mainline to merge.


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com

Andrew Morton <akpm at osdl.org> wrote on 08/21/2005 02:46:57 PM:

> Adrian Bunk <bunk at stusta.de> wrote:
> >
> > Since Urban Widmark was not active for some time, and I didn't have any

> > success trying to reach him, it seems we need a new maintainer for the
> > smb filesystem in the Linux kernel.
> >
> > Is there anyone who both feels qualified and wants to become the new
> > maintainer?
> >
>
> Yes, it's a poor situation.  That driver seems to have quite a few
problems.
>
> I was hoping that by now we could simply deprecate smbfs and tell people
to
> use CIFS, but I'm not sure that CIFS is ready for that yet.
>
> Steve, what's your take?  Does CIFS offer a 100% superset of smbfs
> capabilities?
>
> Thanks.