oplocks

[Lyle Seaman]

Manish Agarwal wrote:

> I have been discussing this with Jeremy .. I would like to correct that:
> The server doesn't send an oplock break but returns an oplock level none
> for the open which caused the break.
> that is:
> say client c1 has a file open with a batch oplock and it has cached some
> writes and record locks against it. Now if another client (c2) tries to
> open the file the NT server would send a break to level2 to c1. If c1
> flushes writes or locks the before sending an oplock acknowledgement ..
> then c2 would get no oplock. If it doesn't, then c2 would get a level2
> oplock.
>
> I must add that this is when all the clients are NT clients (I've seen
> some different behaviour with Win98 .. which I still don't understand
> completely).

Ok, this makes sense.  The NT server is gambling that since c1 has been
trying to write the file before, it is probably going to do it again.  There's
some body of evidence to support this heuristic.  The goal is to avoid
turning around and breaking c2's levelII oplock right away.   Either
behavior is correct -- it's just a performance tweak.

The trick to understanding oplocks is that they're not really locks.
They're leases.  Calling them locks is confusing.  Unfortunately,
they're not really like NFS (Sprite, NFS4) leases either, so calling
them leases might confuse things too.  I'm still wishing for a
better name.