Subject: Mandatory locking attribute

From: "Sergey Klyushin" <[email-masked]>
Date: Tue, 2 Oct 2001 14:44:36 -0400

Is there any way for NFS Client to know in advance (before OPEN), that
mandatory locking
is required for the file? Does NFSv4 has such attribute? Don't we miss it
from NFSv2?

Sergey

---

From: "Sergey Klyushin" <[email-masked]>
Date: Tue, 2 Oct 2001 17:40:26 -0400

I've looked again to locking part of NFSv4 spec. and could not find answers
to some locking questions.
Could anybody clarify them to me?

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?

Windows has EXCLUSIVE_LOCK flag that grants both READ and WRITE access
to lockowner and denies any access to others.
If EXCLUSIVE_LOCK flag is not specified, than locked region will be
read-only for everybody, including lockowner.

2. If NFS lockowner has some region locked with READ or WRITE lock type, can
it
"upgrade" to READ_AND_WRITE lock type?
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)

3. If NFS lockowner has some region locked with READ_AND_WRITE lock type,
can it
"downgrade" to READ or WRITE lock type?
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.
There is no WRITE_ONLY lock type on Windows.

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?

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?
What should Windows NFS Server do with "special" stateids?

Thanks in advance,
Sergey

---

From: Ramesh Shankar <[email-masked]>
Date: Wed, 03 Oct 2001 09:32:50 -0600

It would easier to understand this issue if were to look at the 
differences in locking semantics between the UNIX and more or less 
everyone else. Ignore NFSv4 in the following discussion.

Advisory locking is by default available on most UNIX systems, AFAIK. 
With advisory locking, the system does not check for lock ownership when 
read/write calls are made on a file which has been locked.

With mandatory locking, a file has to be "enabled" for mandatory 
locking. In this case, a locked region can be read/written to only by 
the owner of the lock (of the appropriate type, if shared/exclusive 
semantics are supported). With most UNIX systems, this is the process 
which acquired the lock, not the *particular* handle through which the 
lock was acquired. Specifically, you could open the same file twice, 
lock it via one handle and access it via the other without any issues.

For both advisory locking and mandatory locking, overlapping lock 
acquires and sub-range unlocks are permitted. If you already own a lock 
and you acquire a lock on an overlapping range, the ranges are coalesced 
into one. You can then do an unlock for the whole range or unlock 
partial ranges at a time.

Another peculiarity of UNIX locking, which has stemmed from backward 
compatibility when systems were multithreaded, is that lock ownership 
tracking is at the granularity of a process and not at the granularity 
of <process, file descriptor>. This means if you open the file twice, 
lock it using one and close the other handle, all locks held on the file 
are released!

The rest of the world (Novell NCP, Microsoft CIFS, AFP 3.0 etc) support 
mandatory locking and lock ownership is tracked at the graunlarity of 
<user, machine, process, file handle>. Overlapping byte range locks are 
not permitted and sub-range unlocking is not allowed. One or more the 
above have a special case for a given <machine, user, process, file 
descriptor> when a lock is acquired on a range which is already locked 
or something to that effect.

HTH,

Thanks,

S.R.