From: Mike Eisler (mike@eisler.com)
Date: 01/16/03-02:42:33 PM Z
Message-ID: <3E271939.6070104@eisler.com>
Date: Thu, 16 Jan 2003 12:42:33 -0800
From: Mike Eisler <mike@eisler.com>
Subject: Re: Mandatory vs. Advisory
Stevan Steve Allen wrote:
>
>
>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
>
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.
>
>if everyone (all NFS versions) performs locking (e.g. no advisory 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.
>
>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?
>
I hope not.
>
>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?
>
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.
>
>o) Is it expected that all NFSv3 clients need to support NLM (or
>unmonitored locking) because of mandatory locking?
>
No.
-mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:47 AM Z CST