Subject: RE: [nfsv4] client re-use of lock_owner name

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 19 May 2005 16:58:22 -0400

> I just ran into this case when testing a very green client I've
started
> to work on:
> "P1" on client:
> - Opened "xx" with lock_owner4 name "P1" with seqid# 0
>   - got a sequence of seqid#s started with OpenConfirm
>  - did assorted Ops on "xx"
>  - Closed OpenStateid for the above Open
> a little later
> - Opened "yy" with lock_owner4 name "P1", but with a fresh seqid# of 0
>
> At this point my server replied NFS4ERR_BADSEQID.
>
> Now, looking at the RFC (Sec. 8.1.7 and 8.1.8), it indicates the
server
> can choose to release the lock_owner when there is no outstanding
state
> associated with it, but doesn't seem to clarify if/when the client can
> do something similar (aka forget the seqid#).

I would say that it gives no indication that such a thing is possible.

You have a mechanism where both sides maintan a sequence number that has
to match and if one side just decides to forget the sequence number,
then that can't work.  The stuff about the server dropping it is
an exception because otherwise the server that the spec explicitly 
makes since otherwise the server might have to keep an unbounded amount 
of state.

> I've already changed my client to hold onto the lock_owner seqid#
until
> the associated process terminates (at the least it will reduce the
number
> of OpenConfirms required), but I am wondering what the correct server
> response is for the above case?
> Door #1 - NFS4ERR_BADSEQID as I currently do
> OR
> Door #2 - re-initialize the seqid# and require an OpenConfirm, since
no state
>     is currently associated with the open lock_owner
> 
> I am now leaning towards Door #2, since it seems harmless and would
accomodate
> clients that might choose to re-use lock_owner names.

It may be harmless in terms of direct effect (I wouldn't swear to even
that), 
but it would be a change in the protocol.  It would allow clients to
forget 
the current sequence number and some servers wouldn't work with that, so
that when such clients tried to inter-operate with such servers, they
would
get an unpleasant surprise.  

> So, should I take Door #1 or Door #2?

I think the right answer here is door #1 on the server with the client 
making sure it does not reuse owner strings if it is forgetting the 
sequence information.  It is pretty easy to unique-ify the strings to
prevent a problem when creating new owners.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Thursday, May 19, 2005 4:25 PM
To: [email-masked]
Subject: [nfsv4] client re-use of lock_owner name

I just ran into this case when testing a very green client I've started
to work on:
"P1" on client:
- Opened "xx" with lock_owner4 name "P1" with seqid# 0
  - got a sequence of seqid#s started with OpenConfirm
  - did assorted Ops on "xx"
  - Closed OpenStateid for the above Open
a little later
- Opened "yy" with lock_owner4 name "P1", but with a fresh seqid# of 0

At this point my server replied NFS4ERR_BADSEQID.

Now, looking at the RFC (Sec. 8.1.7 and 8.1.8), it indicates the server
can choose to release the lock_owner when there is no outstanding state
associated with it, but doesn't seem to clarify if/when the client can
do something similar (aka forget the seqid#).

I've already changed my client to hold onto the lock_owner seqid# until
the associated process terminates (at the least it will reduce the
number
of OpenConfirms required), but I am wondering what the correct server
response is for the above case?
Door #1 - NFS4ERR_BADSEQID as I currently do
OR
Door #2 - re-initialize the seqid# and require an OpenConfirm, since no
state
    is currently associated with the open lock_owner

I am now leaning towards Door #2, since it seems harmless and would
accomodate
clients that might choose to re-use lock_owner names.

So, should I take Door #1 or Door #2? rick

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4