On Wed, 16 Feb 2005, Tim Potter wrote:

> On Tue, 2005-02-15 at 18:59 -0500, Michael B Allen wrote:
> > William A.(Andy) Adamson said:
> > > we are considering providing the kernel NFSv4 daemon with a file system
> > > interface for OPEN that could be used instead of the POSIX struct
> > > file_operations->open and which would include deny share bits.

> >
> > This just made me realize my suggestion about modifying Samba to coordiate
> > access checks with the NFS lock daemon is by itself not sufficient to
> > eliminate races with external applications. Your modification would also
> > be necessary. Then the NFS lock daemon could effectively be Samba's lock
> > manager as well and provide proper semantics within the kernel for access
> > checks.

>
> I am pretty sure that under Linux there is coordination within the
> kernel between NFS locks and SMB oplocks so that there can be no data
> corruption. Take a look at the various locktest programs in the
> (samba3) torture testsuite.


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)

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?

Of course, it would also be nice if we could get more POSIX error codes
defined so we can properly indicate to local users and servers why a
particular file open request failed, since overloading EACCES seems bad.

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