RE: [nfsv4] more re: client re-using lock_owner

[Mike Eisler <[e-mail]>]

> I assume this is Mike's obfuscated reply address.
                   ^^^^
                   Eisler

This new address will self destruct once the spammers
find it. (My established correspondents should be able
to use my previous email address, unless they are 
asking me to buy mortgages from Nigerian banks backed by
shareholders who made it big in Viagra sales. Oops,
I've just tripped all your spamassassin filters and you
won't see this).

> [e-mail] wrote:
>  > Here's what bothers me about #2. Let's say reason for
>  > the re-used open_owner is not because the client has
>  > forgotten, but because of a retry of an OPEN,
>  > but the client still remembers the open_owner state.
> 
> If the previous OPEN suceeded the server will have state

Not sure you understand what Trond and I are saying.

Let's say the sequence of events is:

time t: OPEN file 1 (seq 1) -->

   times out/held up somewhere

time t+1: OPEN file 1 [retry] (seq 1) -->

time t+2                     <-- OPEN resp from time t

time t+3: client requences response sent a t+1.

time t+4: OPEN_CONFIRM (seq 2) -->

time t+5:                    <-- OPEN_CONFIRM resp

time t+6: OPEN file2(seq 3) -->

...

time t+n ... time t+n+m (all files for the open_owner closed, all locks released)

sequence number for open_owner is now 1000

time t+n+m+1: OPEN retry from t+1 OPEN retry from t+1 finally reaches server.

          at same time:

time t+n+m+2: OPEN file100 seq (1000) -->

The client, at t+n+m+2 thinks his seq is 1000. If the
server implements door #2, then the open for file100 gets BADSEQ,
because the OPEN at t+n+m+1 is accepted without a BADSEQ.
I believe this will confuse most clients, and perhaps all of
the clients that show up at bakeathons.

>  > If we return NFS4ERR_BADSEQID,
>  > then this doesn't perturb the existing sequence number state
>  > for the open_owner. If we request open confirmation, then
>  > the server has two choices:
> 
>  > 1. Perturb the state. So if the client in fact had not forgotten
>  >    about the open_owner's previous sequence number, the next time
>  >    client goes to use a sequence number from the previous use of
>  >    the open_owner, he gets NFS4ERR_BADSEQID. And gets very
>  >    confused.
> 
> This would only happen if we have a buggy client. If the server
> requests an open_confirm he is telling the client that they

I should have said if the server "requests open_confirm and resets the sequence
number to 2"

> are establishing new state. If a client holds onto
> its old state  after getting a OPEN4_RESULT_CONFIRM it is
> just broken.

This was a retried OPEN that the client has long since
forgotten about, because he has long since achieved success
with that operation.

The client doesn't care if the server is requesting OPEN_CONFIRM;
he's going to drop the OPEN response. He's going to drop it because
the xid of that response does not correspond to any outstanding
request.

The problem is that short of an infinite duplicate request
cache, the server cannot disinguish (1) retried OPENs from (2)
a reset of a sequence of sequence numbers from a 
new OPEN caused by a client that has forgotten about his 
unused open_owner. So he has to maintain the multiple
quantum-mechanics-like states I mentioned, until the next operation.
If the next operation is OPEN_CONFIRM with seq #2 and the matching stateid X,
then the other state associated with sequence #1000 is disposed of. If the
next operation is OPEN with sequence #1000, then the state with sequence#2
is disposed off. So implementing door #2, requires Schrodinger states.

(The point of all this sequence number stuff we (you actually :-) added
to NFSv4 was to dispense with the dup request cache for nasty
non-idempotent operations like open and locks.)

What is missing here is a RELEASE_OPENOWNER operation. With that,
the issue of clients forgetting about unused OPEN_OWNERS would be moot.

The other thing is that OPEN_CONFIRM is a kludge 
(courtesy me), but it was put it save a separate round 
trip to establish an open_owner. Given the separation
between open_owners and lock_owners a separate operation 
for creating open_owners might not be a bad thing. But anyway, 
draft-ietf-nfsv4-sess-01.txt kills OPEN_CONFIRM.


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