On Wed, 16 Feb 2005, J. Bruce Fields wrote:

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

Ahh, I am not familiar with the Linux implementation. I am more familiar
with the FreeBSD implementation (4.x) where reads/writes translate the FH
to a VNODE and call a VOP operation on that. Doing an open/close around
them looks expensive (but does make it easier to handle some things).

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

OK. I was thinking more from the point of view of CIFS and PanFS.

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

And, unless I have not understood delegations, break the other persons

Richard Sharpe, rsharpe[at]richardsharpe.com, rsharpe[at]samba.org,
sharpe[at]ethereal.com, http://www.richardsharpe.com