From: Stevan Steve Allen (scallen@us.ibm.com)
Date: 01/22/03-02:11:47 PM Z
Subject: Re: NFSv4 Advisory vs. Mandatory locking issues
Message-ID: <OF14A04926.5D07E3FE-ON88256CB6.005549B0@us.ibm.com>
From: Stevan Steve Allen <scallen@us.ibm.com>
Date: Wed, 22 Jan 2003 13:11:47 -0700
We are examining the ability to implement various locking models in the
NFSv4 server to support our various customer needs. I am posting here to
verify we are not disturbing any NFS rules or verbiage. Please read the
entire post before replying to specifics.
This post is attempting to answer the following two questions. With the
introduction of NFSv4 mandatory locking support, what are the implications
to unix applications using advisory locking in v3 and v4 environments, and
what are the implications of sharing a file between v3 and v4 users.
This post also introduces an important distinction that an NFSv4 server
customer may now have the ability to decide which locking model is to be
utilized for his solution.
-----------------------------------------
With the introduction of v4 mandatory locking support, nothing has changed
for applications using NFSv3 (locks are still not checked and temporary
implicit locks will not be obtained by the server on the clients behalf).
To support customer solutions where mandatory locking is required, NFS
versions supporting NLM can not be used. (e.g. A v3 enabled server will
not verify or obtain the implicit lock needed to support the customers
mandatory locking solution)
Comment: I do not find a problem scenario where the solution is to provide
both NFS v3 advisory locking and NFS v4 mandatory locking to simultaneously
access the same file. Allowing both advisory & mandatory access may be the
default server environment but I see no benefit or problem being solved
with this approach.
Mandatory locking model. Mandatory locking was introduced in NFSv4 to
support customer solutions which could not be satisfied using an advisory
locking model. Describing NFSv4 as a hybrid locking model is not
recommended, instead NFS attempts to provide a conduit for existing locking
models to be negotiated between a server and client, where current and
future enhancements to NFS locking are attempts to support most or all
common locking models implemented by various platforms and allow a given
model to be negotiated between dissimilar client/server platforms.
In NFSv3, the need to lock can not be controlled or enforced by the NFS
server. Unlike v3, v4 now allows the customer to implement on the server
platform the ability to restrict which locking models are allowed in the
distributed environment based on a files access needs, platform
requirements, or the requirements of a given solution. The NFSv4 protocol
now provides an NFS server customer (probably the storage admin) the choice
to decide on a file by file, file system, or NFS server basis the locking
model needed by a given solution, and enforce that model from the server
end. This is contrary to the UNIX world where the application decides if
locks are needed. NFSv4 locking therefore allows the server customer to
implement platform specific locking solutions which may refuse access to
clients using different locking solutions. This is not true in an NFSv3
environment.
We are examining the following NFSv4 server solution. Verbiage may be
specific to our platform.
The NFSv4 draft does not describe (or exclude) the differences between
various mandatory locking models implemented on various server platforms.
On a file by file basis, an NFS server customer may select one of the
following locking models supported by NFSv4.
o Advisory Locking
o Mandatory where a lock will be obtained on behalf of the client
for implicit lock operations (using advisory locking)
o Mandatory where implicit locking is not allowed (fail request)
option describes a solution where strong locking is needed.
An interesting clarification is that a v4 client/appl does not know
beforehand if the server is supporting advisory or mandatory locks. An
unprotected request will not conflict with locks if the server is running
v3, or v4 in advisory mode. If the request is v4 with the server
implementing mandatory w/ implicit locks, the unprotected i/o request may
now fail (conflicting lock) where it would have been successful using
advisory locking. If the request is v4 with the server implementing
mandatory w/ only explicit locks allowed, an unprotected request will
always fail. If the server has disabled NFSv2/v3 access and has
implemented a v4 mandatory locking solution, v2/v3 requests will fail while
v4 implicit requests may have the lock obtained on their behalf, or the
request failed if explicit locking is required.
Thanks,
Stevan C. Allen
Winston Churchill:
"A Riddle wrapped in a mystery inside enigma."
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:47 AM Z CST