Subject: Mandatory vs. Advisory

From: Stevan Steve Allen <[email-masked]>
Date: Thu, 16 Jan 2003 11:51:52 -0800

At my location we are attempting to evaluate the need to add NLM support to
our NFSv3 client due to NFSv4 mandatory locking...

Someone locally made the statement that NFSv4 mandatory locking is provided
solely to insure "data integrity".  And data integrity can only be provided
if everyone (all NFS versions) performs locking (e.g. no advisory locking
allowed).  To provide data integrity, a server implementation may decide to
enforce mandatory locking for NFSv3.  The last statement contradicts the
original NFSv3 protocol which assumes the nfs server is unaware of what
locks are held (by lockd) while processing a client read or write request.

The questions are:

o) Is anyone planning to enforce mandatory locking on their server for
NFSv3?
o) If a NFSv3 client does not support NLM and an NFSv3 server requires
mandatory locking (describes a failure case with no user bypass), are
both/neither considered to be abiding by the NFSv3 protocol?
o) Is it expected that all NFSv3 clients need to support NLM (or
unmonitored locking) because of mandatory locking?

Thanks for any clarification.

---

From: Mike Eisler <[email-masked]>
Date: Thu, 16 Jan 2003 12:42:33 -0800

>solely to insure "data integrity".  And data integrity can only be provided

I disagree. It's there because there are Windows and UNIX APIs that use
it. Of course, those who created those APIs might argue they did so for
the sake of data integrity. But they would be wrong. Advisory locking
works just fine for preserving data integrity, and as I point out
below, for NFS, it actually works better than mandatory locking.

>allowed).  To provide data integrity, a server implementation may decide to
Where is that written?

>enforce mandatory locking for NFSv3.  The last statement contradicts the

Adding mandatory locking to NFSv3 can't work, because if the client has
used NLM to lock the affected range, the server can't tell if the client 
process
that is writing to the file is the same one that locked the affected range.
This is one reason why, in NFSv4,  I/O operations include a stateid
to identify the "lock owner" (aka, the UNIX process id) that is
doing the I/O in order to compare it to the lock owner than
got the lock.

>o) Is anyone planning to enforce mandatory locking on their server for
I hope not.

>both/neither considered to be abiding by the NFSv3 protocol?

I know of no such NFSv3 servers that require mandatory locking.
If the mandatory lock bit is on the file, then typically the server
disallows access to the file.

I can imagine some NFSv4 servers might attempt to get
a non-blocking lock on the affected range, but it's rather
pointless since the data integrity argument only holds if
client locks the file through a critical section involving multiple I/Os.
And since NFSv3 will require the client to break a
large write() or read() request into several I/Os, having the
server locking  and unlocking each affected range
is useless.

>unmonitored locking) because of mandatory locking?

No.

    -mre