Re: [nfsv4] Read delegations and LOCK operation

[Trond Myklebust <trond.myklebust at fys.uio.no>]

On Wed, 2009-10-28 at 16:06 -0700, Mike Eisler wrote:
> > The Windows 2000 client will just have to wait if it decides to try to
> > set a write lock on a file which it opened for read only.
> 
> It won't necessarily have to wait.
> 
> If the non-Linux/non-Windows client and server are following
> a different semantic such as an advisory exclusive byte lock
> is allowed on a file open for READ, then the server will grant the lock
> despite the delegation on the Linux client. Then later, when the
> Linux client flushes its conflicting byte range shared lock on the file,
> the LOCKU will fail because the non-Linux/non-Windows client has the
> lock. That's what the Linux client gets for failing to honor:

I'm not sure this is true...

AFAICS, given that the effect of the LOCK(WRITE_LT) request is to deny
clients the right to read the file, then such a request really MUST
cause an immediate recall of any outstanding read delegations.

If it doesn't, then there is no way for clients that are holding
delegations and caching the data, but that aren't using locking to know
whether or not a lock is in effect. Ignorance being bliss, they will
happily ignore the lock.
While applications that are written for a POSIX environment do not care
one way or the other, the Windows applications running on clients that
hold a read delegation might.

Cheers
  Trond