Subject: Re: Client<-->Server using both NLM & NFSv4

From: "Stevan Steve Allen" <[email-masked]>
Date: Fri, 13 Sep 2002 13:40:57 -0700

Spencer,

Server implementations may hash the separate nlm versions & v4 locking
calls to the same client identification (such as a host block).  This
worked well when locking different versions of NLM, as a single sm_notify
would represent a lost lock state by all (one) locking protocols & protocol
versions.  This is no longer true with the introduction of a second locking
protocol (orig note).

I suppose a server is allowed to implement a design where a single
sm_notify (or setclientid) may purge both nlm & v4 locks and return stale
if the client actually did not loose all locks.  An example is where nlm
restarted but not the nfs v4 client.

I also take it that -you believe- most nfs servers will not purge v4 locks
for sm_notify, or visa versa.

I was asking for verbiage which states the server must not or should not
purge nlm locks for setclientid, nor purge v4 locks for a sm_notify from
the same host.  Such verbiage goes a very long way when dealing with
compatibility issues between products as they arrive.  Are such
compatibility topics candidates for the V4 draft?

Forgive my newness in this open arena, but if this is an item for some
other recommended implementation standards not handled by this forum, is
there another shared vehicle which is geared to nfs implementation
standards (my second attempt for adding verbiage).

Thanks,
Stevan C. Allen

On Tue, Stevan Steve Allen wrote:
> A single client may have both NLM & NFSv4 sessions established with the
> same server.
> It was noted that a client NLM restart does not signify a client reboot.
> NFSv4 locks are still valid.
>
> Based on separate protocols, It would seem that an sm_notify does not
mean
> the server should throw away NFSv4 locks, or visa versa for setclientid.
> This indicates the NFS server needs to differentiate (track) NLM & V4
> locks... and server locking functions such as purge locks by client id
> needs enhanced so only the proper version of locks are purged.
>
> For a full client system restart, we believe there will be both sm_notify
&
> setclientid issued to the server.  And it takes both to clean up all
locks.
> The NFSv4 locks may timeout when missing a setclientid, but nlm locks may
> not timeout if missing an sm_notify.
>
> Is anyone adopting the server approach that a lonely sm_notify  -or-
> setclientid releases all lock versions?

I don't see how a server implementation could provide this since the
identification of the client is different between NLM and NFSv4.  The
server can not determine if two requestors/clients are the same or if
they are different.

--
Spencer

---

From: Mike Eisler <[email-masked]>
Date: Sat, 14 Sep 2002 14:06:41 -0700

>compatibility topics candidates for the V4 draft?
Such verbiage would be useful but in my opinion should not be a 
requirement to
published the internet draft as an RFC. In other words, I think the 
deadline for this
change has passed. It sounds like something to mention if and when NFSv4 
is raised from
a Proposed Standard to a Draft Standard.

    -mre

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 16 Sep 2002 21:06:18 -0500

> a Proposed Standard to a Draft Standard.

While I am not opposed to adding language for this, I am not sure I
fully understand where the confusion would be introduced in the first
place.  The NFSv4 specification does not talk at all about interaction
with a co-resident NFSv2/v3 server nor any other co-resident file
server protocol and it speaks very little about local access.

For this specific issue, I just don't see where the client identifier
used in NFSv4 would be confused with the client identifier used for
the NSM/NLM protocols.  In fact, the server can make no assumption at
all about what the client has chosen for an identifier and must not
have the v2/v3 notification procedure interact at all with the NFSv4
notification procedures.  Maybe this is the verbage that is desired in
the specification.

In general, if we are going to go down this path, then there are much
more important issues with respect to NFSv2/v3 interaction in say, the
case of the NFSv4 delegation functionality and recommendations that
should be made with respect to implementation at the server.

Therefore, I would assume that most of these (if not all) issues be
included in any implementation recommendation text.

-- 
Spencer