Subject: Benefits of Mandatory Locking

From: Stevan Steve Allen <[email-masked]>
Date: Tue, 3 Jun 2003 23:46:00 -0700

Given the following mandatory locking scenario using magic stateid's, I'm
having difficulty listing any claims or benefits the mandatory locking
model provides which the advisory model does not.

1. Appl 1 issues a large write
2. Large range is broken into two RPCs
3. 1st half of write is sent to the server with a zero stateid
4. No lock conflicts, partial write is successful and completes

5. Appl 2 successfully locks the entire range of Appl 1's write
6. Appl 2 successfully writes entire range overlaying Appl 1 partial write
7. Appl 2 releases associated lock

8. 2nd half of Appl 1 write is sent to the server with zero stateid
9. No lock conflicts, partial write overlays Appl 2 change

If the above scenario describes writing an image file, the resulting
picture can be described as a mans head on a ducks body.

To ask the question in another way,  could an advisory locking server using
ACLs to limit access to trusted applications provide the same benefits as
an mandatory locking server?  If not, what is missing?

On a different topic....  Someone once said unless a lock conflict is
detected and nfs4err_locked is returned, the NFS client and client
application will not be aware that a mandatory or advisory locking
environment is in effect.  e.g. the application can perform all it's
operations and end successfully without ever knowing.  Given this, I assume
any application written to handle the mandatory locking error will also run
unknowingly and unaffected in an advisory locking environment.  e.g.
mandatory applications have no problems with advisory servers.

Thanks,
Stevan C. Allen

---

From: David Robinson <[email-masked]>
Date: Wed, 04 Jun 2003 08:37:55 -0600

> 9. No lock conflicts, partial write overlays Appl 2 change

This demonstrates the risk of using a zero stateid and why
it should not be encouraged when data consistency is needed.
This problem exists today with NFSv3/NLM, multiple clients
following proper locking protocol can get their data wiped
out by a non-participating client. Even if Appl1 doesn't
use a zero stateid, but instead only locks the subrange
in each request, corruption occurs, in both cases this
is a programming error.

> an mandatory locking server?  If not, what is missing?

If you have applications that are using locking, it is very
reasonable to use ACLs to disallow users that may want
to run applications that don't understand the locking
convention.

I think there may be a difference in the use of the term
"mandatory". (It does have different semantics between
SYSVR3 Unix and Windows). In NFSv4, mandatory means that
an I/O operation using a normal stateid will get an error
back when a conflicting lock exists.  If no locks exists,
no I/O operation will fail with a locking error. Mandatory
doesn't mean that you have to use locking, it only means that
when you do lock a range, for the duration of that lock
you will not get a conflicting I/O operation.  But it is
still the requirement of applications to set locks as
they see fit.

There are two motivations of the design, the first was the
incorporation of a stateid in I/O operations so there
could be a correlation between a client holding a lock
and the I/O.  Before, if a request got reordered or delayed
due to a networking problem, a client diligently following
locking could clobber its own data. But it was still presumed
that the client would still be responsible for determing
what I/O operations will be issued with a lock and those
without.  The stateid just allows the server to catch cases
where I/O issued based on the clients understanding
of the "current" state, are still valid. The second
decision was to decide if we should cause I/O
operations to fail when they conflicted with a lock.
In the core Unix base this was unneeded, and actually
unwanted by a lot of folks.  But in the Windows
world they have the semantic that the I/O must not
complete it a conflicting lock is held.  So we added
mandantory locks to cover all bases.

But what we never did was to setup a mode where the
server can tell a client that it could only do
I/O operations when a lock was held.  Frankly I
never heard anyone even suggest such a thing, although
I now can see how it could be useful. Minor version
anyone?

	-David