Dual-protocol support
From Linux NFS
You can export the same filesystem over SMB and NFS today, but there are some problems. Here's a list of known problems we want to think about before we can really recommend this.
This is focused on in-kernel disk filesystems exported using Samba and knfsd. There are people interested in using Ganesha, and in other filesystems (glusterfs, ceph, etc.). They'll probably face some of the same problems.
A general problem here is a lack of clear use cases or tests to let us know when we've succeeded at this stuff.
Contents |
ACLs
Our exported filesystems currently only support "posix" acls. NFSv3 has a sideband protocol that supports similar ACLs.
SMB and NFSv4.* support Windows-like ACLs, but use complicated (and different) translations between those ACLs and the backend "posix" acls.
Our current plan involves merging kernel support for Andreas Gruenbacher's richacls.
To what extent do Windows applications depend on them? (My impression is: enough that if we just failed any attempt to acquire them then important applications wouldn't work.)
Samba enforces these itself, possibly with the help of a flock with LOCK_MAND. (See [the comment above the definition of the flock syscall in fs/locks.c].) There are races on create (I believe Windows applications should be able to atomically create and acquire share locks).
knfsd enforces [share locks] itself (so NFSv4 share locks aren't seen by anyone but other NFSv4 clients.)
I seem to recall NFSv4 also has fewer open share types than Windows--does that matter?
In practice NFSv4 users of open deny bits are probably very very rare. Could we get away with allowing servers to fail them with NOTSUPP or something?
As a workaround turning off NFSv4 completely might help.
byte-range locks
NFS and SMB both define byte-range file locks with different semantics. How should they interact? If we can't make them work right, is there a way to turn off support for them completely, or would that break too many applications?
caching
Samba and NFSv4 both have mechanisms (oplocks and delegations) that allow clients to cache data until they get a revocation from the server.
Samba implements SMB oplocks itself, possibly with help from the kernel's lease subsystem. I seem to recall that its use of leases is somewhat limited (maybe it only uses write leases?), and that the leases are missing some needed features (upgrades and downgrades, for example?). Also, I believe newer SMB protocols have introduced some more complications.
NFSv4 has an in-kernel delegation interface that's used to implement NFSv4 delegations. It should interact correctly with local users and users of the lease interface. We only support read delegations for now, but write delegations might come some day.
Do SMB clients do in the absence of oplocks?
As a workaround, maybe we could just turn off delegations and/or oplocks at first.
NFS clients tend to do close-to-open caching by default. I don't know if that will cause any issues. Again we kind of need use cases here to define success.
Are there any directory caching issues? At least on the NFS side directory operations are all synchronous, and there is no notion of directory delegations (well, there is, in rfc 5661, but nobody's implemented it), so I think we're probably OK here.
user mapping
Presumably Samba already has adequate mechanisms for this for now?
open/unlink behavior
My understanding is that Windows hasn't traditionally allowed unlinks of open files. Does it cause problems when unix clients unlink files out from under them? How does Samba handle this, and does the presence of NFS make this any worse?
other
What have I missed?
