Re: CIFS VFS

["Steven French" <sfrench@us.ibm.com>]

Sure.   This had been discussed among the Samba community starting at last
year's CIFS conference and again at the plugfests and interoperability
events this year.
I do not view the CIFS VFS as necessarily replacing smbfs, since smbfs
provides
interoperability with older servers (prior to NT 4) which is still of value
to some
users.   There were basically three reasons that we did not start from
smbfs and
felt that an additional filesystem was necessary to support the newer
version of the protocol.

1) Limited reuse potential - smbfs was missing quite a bit of the newer
function needed
which after looking at for a while and seemed easier to implement from
scratch rather
than try to force fit into smbfs, and customers could then choose whether
they wanted
to use the newer more experimental CIFS vfs or the older smbfs.

2) The recommendation of one of the previous smbfs maintainers (and some of
the Samba team)
last year who put a complete rewrite of smbfs fairly high on the list of
the "samba-related"
items that needed to get done.  Comments included perceived design problems
in the original
design of smbfs,  lack of structure definitions for most key protocol
elements and no support
for a few key Samba features.

3)  smbfs seemed to have different design goals including broad
compatability with old
servers (much like nfs v2 provides broad compatability vs. nfs v4 which
provides useful new
function) while we wanted to take advantage of features only available in
current servers
and also to provide a more useful reference implementation for the client
end of new
extensions to CIFS such as the CIFS Unix Extensions (Samba already provides
this
for the server side) as our work in the CIFS Technical Workgroup in the
Storage
Networking Industry Association continues.   In addition there were other
design differences
that were fairly fundamental - an important chunk of smbfs is implemented
in user space,
which makes implementing ms dfs (heirarchical name space) difficult and
would make it
impossible to boot (diskless systems) from and also complicates
reconnection.   Finally
another big difference in design goals is that smbfs preferentially uses
Netbios naming and
port 139 (as it should as an smb filesystem) while the CIFS VFS
preferentially
uses TCP naming and port 445 (as CIFS systems are supposed to) although it
can fall
back to 139.

The design goals that we started with were the following.   Most of these
were not
implemented in smbfs when we started, although a few have been added to the
kernel as patches (e.g. on Urban's web site) and others.

Features we have implemented in the CIFS VFS so far:
1) "Pure TCP/IP" (port 445 in addition to RFC1001 port 139) support  (NB
the
mount.cifs mount helper, needed for calling gethostbyname, is not quite
complete)
2) Full POSIX support including use of CIFS Unix Extensions and NT
hardlinks etc.
3) Support for "raw NTLMSSP" (security negotiation) and more secure session
establishment
4) Large file handling (larger than 2GB up to 2**63 in size)
5) Internationalization improvements (Unicode on the wire)
6) Use of SetPathinfo instead of SetFileInfo where appropriate, use of
current levels for
CIFS transact2 calls
7) Use of 32 bit errors (cifs network status codes) vs old dos error codes.
8) Byte Range and File locks
9) Improved support for Symbolic links  (NB Samba bug blocks some
POSIX test cases for some types of symlink names)
10) Improved debugging, procfs support
11) Case sensitive searches (done) and Unix behavioral defaults

Features that are being worked (in progress):
1) Transparent reconnection  after tcp or cifs session failure
2) Globally rooted, AFS-like heirarchical name space
3) Kerberos/SPNego authentication
4) NTLMv2 encryption
5) Distributed Lock/Token Management (e.g. Level I and II oplocks) -
safe client data caching
6) optional Multiple security contexts and transparent local to network
UUID mapping
7) Performance improvements (e.g. command chaining, overlapping multiplexed
PDUs to same server, reduced copy overhead, gather send using multiple
iovecs,
optimized dialect usage)

And features that we will be starting on next:
1) Per SMB security signatures (needed in many cases for .Net server
compat)
2) Replicated volumes
3) Mounts to multi-component UNC names (mounts to
4) Improved PAM/NSSwitch module integration (if a network authentication
module such as Winbind or PAM_Kerberos or PAM_LDAP are configured, for
example)
5) Network alias support (not started)
6) Directory and File change notification for optional safe caching of
inode metadata (not started)
7) Support for CIFS ACLs and xattr support (not started)
8) Improved Support for Disk Quotas (not started)
9) CIFS Sparse files and some related network IOCTLs (not started)
10) Offline files and CIFS heirarchical storage support


The CIFS VFS has been going through lots of interoperability testing,
starting at Connectathon
and including this years CIFS Conference and plugfest (smbfs was not tested
at these).   IBM
developed the initial smb filesystem years ago and it is still the "native"
remote filesystem
for OS/400 (and of course IBM PC-DOS and OS/2) so it also seemed
appropriate that we
should help out Linux interoperability in this area especially given the
explosion of storage
appliances that implement CIFS and also the large number of Windows and
Samba servers.


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