Re: CIFS VFS

[Urban Widmark <urban@teststation.com>]

On Tue, 1 Oct 2002, Steven French wrote:

> 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

A vast majority of smbfs users are using NT4+. win9x is noticable but the
others are not making a lot of noise. Under those circumstances I think
having two filesystems for the same thing is a waste of resources (time).

I would suggest a replace or a merge. Not really sure how such things are
decided or if it is possible to get some idea in advance what the higher
authorities would prefer (Al?).

If smbfs should be replaced, or be placed in maintenance-only mode, then
there is no point in trying to introduce smbconnect before 2.6/3.0.


> 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.

I personally feel that none of the issues in this point is very strong:

+ Compatibility with old systems can be provided with function pointer
  "classes" (see struct smb_ops in fs/smbfs/proc.c). So eventually the
  open call for os2 is different from the one used with win3000.

  This is more or less how the unix extensions was added.

  Old stuff can be moved to a smbfs_oldies.o module and doesn't even have
  to take up any space. There will still be a lot of things that can be
  shared. And if it breaks and you can't test it, wait for some poor soul
  that uses os2 and get them to send tcpdump's - that's what I do now.

  I believe nfs v2 vs v3 is supported by the same kernel module in this
  manner. Unlike nfs, smb/cifs doesn't have such strict versions.

+ smbmount is completely replaceable, nothing of the "internals" of smbfs
  is really connected to it. It is even possible to have both in-kernel
  connection code and a userspace tool at the same time.

  The big advantage of smbmount is that it reuses samba code, so in samba
  3.0 adding kerberos support to smbmount is (AFAIK) a matter of doing:

	"c->use_kerberos = 1;"

  CIFS VFS will have to bring the kerberos code into the kernel, or?
  If you don't you will depend on the userspace helper in exactly the same
  way smbfs depends on it.

+ The dfs stuff is possible to solve by changing smbmount to be a tool
  only for making connections (/bin/mount would mount smbfs directly).
  This "smbconnect" can be called the same way modprobe is run. I have
  rough but functioning patches for this vs 2.4.14.

+ Can't diskless systems use initrd?
  People that have asked about these things seem more troubled by the size
  of smbmount (the drawback of being a part of samba).

+ Isn't the difference between port 139 vs 445 only in the setup part?
  Well, if it is then that's handled by libsmb and smbfs really doesn't
  care. If not it's not a huge change.

The other two reasons aren't really described in enough detail (and this
letter is too long anyway). But that doesn't matter. I don't see the code
in the two being so different that you can't copy how things are done
between them.


> 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

No, the pricetags for both are significantly over my testing budget.
I'm not terribly fond of signing NDA's either ...

/Urban