kernel support for open share modes

[J. Bruce Fields]

On Tue, Feb 15, 2005 at 09:27:44PM -0800, Richard Sharpe wrote:
> Part of the problem with any existing scheme that works in an NFS v3
> environment is that it cannot really work properly. There are simply too
> many race conditions. For example:
> 
>    NFS client read a file using a file handle it already has
>    smbd opens a file and applies an OpLock using the Linux interface
>     (however, it has no idea that an NFS client has cached some data)

I'm not sure there's a problem here.  In the NFSv3 case, nfsd does an
open and close around every IO operation.  So the first time that NFS
client tries to write back dirty data, the resulting nfsd open breaks
smbd's lease.

The NFSv3 client may not see writes from smbd's client as soon as it
otherwise would, but this isn't necessarily a problem.  No version of
NFS gives the same cache consistency guarantees as a local filesystem.
They only guarantee that dirty data is flushed before closes return, and
that caches are revalidated before opens return.

In the NFSv4 case on-the-wire opens and closes translate roughly into
local opens and closes, and we use the same lease interface for
delegations.

> It seems that the model of a new open call that allows the specification
> of share-mode bits is a step in the right direction for CIFS
> compatibility. Does the NFSv4 delegation model separate out file opens and
> delegations, or is it all done at file open time?

Delegations are done at file open time.  But they're also entirely at
the server's discretion--so we can open the file, try to get the lease,
and not be concerned if someone else beats us to it--we can always just
return a succesful open without a delegation.

So the problem is the share bits, which we don't have the option to
ignore.

--b.