Subject: RE: locking semantic (UNIX vs. Windows)

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 3 Oct 2001 07:07:55 -0700

Sergey Klyushin wrote: 
> I've looked again to locking part of NFSv4 spec. and could not find answers
> to some locking questions.

There are a lot of questions that are not explicitly addressed in the spec.
I think there are things on the issues list to address at least some of 
them.

> Could anybody clarify them to me?

I can tell you my interpretation.

> I'll provide what Windows is doing locally.
> 
> 1. First, lock semantic on Windows is slightly different from NFSv4:
> NFSv4 has READ and WRITE lock_types and they can't be combined in 1 request.
> Does it mean from NFS point of view, that lockowner with WRITE lock type
> can't read locked region?

I think READ and WRITE lock types might better be called SHARED and
EXCLUSIVE.  In the case of advisory locking, that is precisely how they
behave.  

The case of Unix mandatory locking is more complicated.

> Windows has EXCLUSIVE_LOCK flag that grants both READ and WRITE access
> to lockowner and denies any access to others.

This is how Unix WRITE locks work when mandatory locking is in 
effect.  It doesn't stop the lock holder from reading.  This
behavior is not described in the spec, but I believe that was
the intention.

> If EXCLUSIVE_LOCK flag is not specified, than locked region will be
> read-only for everybody, including lockowner.

I believe that the model for Unix mandatory is slightly diferent 
from that.  You can read or write if and only if there is no 
conflicting byte-range lock held.  Impelmentations may differ
on this point but I believe that in your example, a write
by the lockowner would be allowed since it doesn't conflict
with a shared lock that that lockowner holds (but it would
conflict with a shared lock held by a different lockowner
so that two lockowners hold shared locks for the same region,
neither could write).  Anybody who's looked at the Unix
code for lately care to comment?

> 2. If NFS lockowner has some region locked with READ or WRITE lock type, can
> it
> "upgrade" to READ_AND_WRITE lock type?

The spec isn't explicit on this point but my assumption has been
that if you have a READ (shared) lock you can upgrade to a
WRITE (exclusive) lock by just having the same lockowner
request a WRITE lock for the region.

> Windows: can have READ_AND_WRITE lock type providing EXCLUSIVE_LOCK flag on
> FIRST lock.
> If EXCLUSIVE_LOCK flag not specified on FIRST lock, there is no way to
> "upgrade" from
> READ to READ_AND_WRITE lock type (only unlock and lock again)

Not sure what you are saying here.  Are you saying that Windows does
not allow upgrade at all, or that it is only allowed after downgrade,
or something else?

> 3. If NFS lockowner has some region locked with READ_AND_WRITE lock type,
> can it
> "downgrade" to READ or WRITE lock type?

It isn't stated explicitly but the spec implies that you can
downgrade by the same lockowner just getting a READ lock for
the same range.

> Windows: can have READ_AND_WRITE lock type providing EXCLUSIVE_LOCK flag on
> FIRST lock.
> It's possible to "downgrade" to READ lock type, sending another lock without
> EXCLUSIVE_LOCK flag.

That matches the POSIX handling.

> There is no WRITE_ONLY lock type on Windows.

There is no Unix lock type that only allows you to write.
I don't think I've ever heard of a system that has one for
byte-range locks.

> 4. Lockowner already holds some region and sends request to lock it again
> (not retransmission, seqid OK, stateid OK, same lock type).
> Should request be granted or denied?
> In case that request should be granted, how many unlocks client should send?

POSIX locking will always grant it and you only have to do a single unlock.

I had assumed that that behavior was not required by the spec
and that a server had the option of doing something more ... sane.

In the case of EXCLUSIVE locks, I think it is pretty clear you 
can just deny it.  ("Hey.  There's an exclusive lock.  What part
of 'exclusive' don't you undertsand?") 

The case of SHARED (i.e. READ) locks is more interesting.  You 
don't have grounds for an ordinary denial since any number of
READ locks can co-exist.  On the other hand, just accepting it
normally and therefore requiring two unlocks would screw up
clients who expect POSIX behavior (sine they would expect to
only need a single unlock).  So I would argue that unless you
are of the POSIX persuasion you should reject this but I'm not
clear what the error would be.

> 5. Lovely special stateids.
> Windows: If region is locked with EXCLUSIVE_LOCK flag by local application
> or
> by some NFS lockowner, than it could not be read and written to.
> If region is locked without EXCLUSIVE_LOCK flag it could be read. (question
> of SHARING)
> If region is NOT locked at all it could be read and written.  (question of
> SHARING)
> What kind of mandatory or advisory locking could be provided in such case?

With the appropriate substitutions of WRITE lock for EXCLUSIVE_LOCK, etc.,
this is my understanding of how mandatory locking would work for NFS-v4,
with one exception.  The case of a read with stateid all ones of a region
that is locked for WRITE is treated differently.  The spec says that this
is allowed to go through although it can be read as implying that this
behavior is optional on the servers part (and it also could be read as
requiring it).

Advisory locking is simpler.  It has no effect on IO at all.  READs 
and WRITE can go through regardless of any conflicting byte-range locks.
If Windows can't do that, it doesn't have to.  Advisory or manadatory
locking is a choice that is up to the server.

> What should Windows NFS Server do with "special" stateids?

Treat them very nicely and hope they go away real soon :-)

---

From: "Sergey Klyushin" <[email-masked]>
Date: Thu, 4 Oct 2001 15:58:58 -0400

> -----Original Message-----
    > From: Noveck, Dave [mailto:[email-masked]]
    > Sent: Wednesday, October 03, 2001 10:08 AM
    > To: 'Sergey Klyushin'; [email-masked]
    > Subject: RE: locking semantic (UNIX vs. Windows)
    >
    >
    > Sergey Klyushin wrote:
Thanks

    > EXCLUSIVE.  In the case of advisory locking, that is
OK with me
    > with a shared lock that that lockowner holds (but it would
No. If lockowner used lock without EXCLUSIVE_LOCK flag and there are no
conflicting locks,
Windows still doesn't allow write even for lockowner. And this is one of the
reason why
advisory locking could not be implemented on Windows.
stateid of 1's could not be implemented, because if there is lock with
EXCLUSIVE_LOCK flag
nobody can read from locked region except lockowner, that could be local
application which is
out of control of NFS Server.
Looks like Windows is mandatory locking only.
    > not allow upgrade at all, or that it is only allowed after downgrade,
Windows does not allow upgrade at all, i.e. there is no possibility to
upgrade
from READ (shared) lock to WRITE (EXCLUSIVE) lock. To do so, Windows has to
unlock
READ lock and set new WRITE lock. Everything could happened in between.

---

From: David Robinson <[email-masked]>
Date: Thu, 04 Oct 2001 15:55:40 -0500

> Looks like Windows is mandatory locking only.

If NFSv4 supported the concept of explicitly requesting either advisory
or mandatory locks, I believe Windows could support it.  The trick is
that the Windows server would have to maintain a seperate list of
locks and then open the file with no restrictions. Interaction
with applications that do expect mandatory locking becomes the
interesting part of the specification if anyone has the desire to
add in advisory locking.

	-David