Subject: Fw: Benefits of Mandatory Locking

From: Stevan Steve Allen <[email-masked]>
Date: Wed, 4 Jun 2003 20:05:33 -0700

David Robinson wrote:
|Stevan Steve Allen wrote:
|> 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
|
|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.

In a data consistency environment, you just described a client which locks
on the application behalf but does not know the full range of the appl
write request as a buggy client.  I agree.

|> 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?
|
|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 determining
|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.

That was interesting and helpful.  If I interpreted your response
correctly, the problem/solution you just described refers to data
consistency.  i.e...

Mandatory locking provides the NFS server the ability to detect
transmission reordering.  In an environment of knowledgeable applications
performing expected locking semantics, the NFS mandatory locking protocol
will verify the i/o to the lockowner & file share to detect transmission
reordering.  NFS4ERR_LOCKED will be returned when an incorrect transmission
order condition is detected.  Mandatory locking provides a reasonable
expectation of data consistency given a stable environment limited to
trusted applications.   Servers which grant a write using a special stateid
negates the data consistency benefit just described.

For reorder detection, I would assume a no lock held condition also must
indicate a reorder problem (or buggy appl) and an error will be returned.

|----------------------------------------------------
|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.

To limit my initial topic..  Given a different mandatory environment where
the server is a core Unix (not Windows), and data consistency is "not"
enforced, and non lockers using special stateid's are allowed as defined in
the draft, I do not see a server claim or benefit being provided by
implementing the mandatory locking model  "with" special stateid's that an
advisory locking model can not provide.  It seems the only servers which
benefit from mandatory locking is Windows & some Posix implementations
which require data integrity.

I don't see any of the core Unix base platforms you mentioned will benefit
from these two locking decisions and suspect they will not implement
mandatory locking based on these decisions.  If they do, I would still
setup advisory locking for performance without fear of loosing any ability
or compatibility concerns.  Basically, if your going to allow magic
stateid's I don't see any benefits.

I'm also interested in what problem/solution Windows implementations are
solving with NFS mandatory locking if they are allowing magic stateid's
(it's won't be data consistency).

|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

---

From: David Robinson <[email-masked]>
Date: Thu, 05 Jun 2003 12:27:43 -0500

> indicate a reorder problem (or buggy appl) and an error will be returned.

Close, the actual error will be NFS4ERR_OLD_STATEID as every operation
that causes locks to change issues a new stateid effectively
invalidating and outstanding I/O requests. I would changed the
term "trusted" to "cooperating" applications, trust has more
implications than I would be willing to make.

Whether there is no lock held or a different lock really is
not important. The server is receiving an I/O request that
indicates it was made during a state that no longer exists
on the server, thus an error is returned even if the current
state would not otherwise cause and error (e.g. no locks held).

> stateid's I don't see any benefits.

Pretty much most Unix implementations have no use for mandatory
locking and we will see how widely it is implemented. It has
nasty implications when something leaves a mandatory write lock
on a file such as /etc/passwd causing a massive denial of
service.  Conversely, without mandatory locking an interesting
number of Windows applications will be unsupportable, magic stateids
were the hack to bridge the gap.

> (it's won't be data consistency).

I don't know how the Windows implementers will handle this...

	-David