Subject: [nfsv4] BAD_SEQID vs OPEN_CONFIRM discussion

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 26 May 2005 14:54:24 -0400

This is *not* an attempt to re-open the discussion of this issue.  I'm
attempting to fairly summarize the discussion in a small number of 
paragraphs.  (Spencer asked me to do this.)  My intention is to be fair
to all participants and let me know if you think I haven't been.  On
the other hand, the whole point of this summary is to compress the
discussion into something people will find easy to read so please be
understanding if I haven't done full justice to all your arguments.
It just isn't possible without making this much too big.

Rick Macklem raised the question of the best handling if a server 
receives an OPEN request with a sequence id which does not match
the one which the server expects.  Clearly the server may return
BAD_SEQID, but is it correct/desirable for the server, in the case in
which there was no current open state for that owner, to instead
accept the OPEN, respond indicating that confirmation is necessary,
and update the current seqid for that owner upon receiving that 
confirmation?

The question at the heart of this discussion is whether there are 
situations in which a client may legitimately find itself unable to 
determine the correct next sequence number for a given owner, making
some help by the server desirable, specifically in the form of
acceptance 
of a non-matching seqid (subject to confirmation).  Although there
was general agreement that because a server is free to drop an owner
when there is no open state, asking for confirmation (as opposed to
returning BAD_SEQID) was within the spec, beyond that point there was
a sharp division of opinion.

David Robinson argued that accepting the OPEN and asking for
confirmation
was the desirable course and in fact stated that if this had been
brought
up before the spec was finalized he would have pushed to make this
alternate
behavior a "MUST".  His argument was, in part, that simple clients might
forget particular open_owners, and then later create new owners with the

same opaque string and a new seqid sequence, presumably one beginning at
zero.  Given this context, he argued that a server which accepted the
new
seqid for that owner, was being friendlier to the simple client, and
avoiding the extra round trips that would be necessary for the client to
find a owner string that the client was not still tracking.

Others argued strongly to the contrary.  There were two basic points of
disagreement with David R's position.  First, it was pointed out that, 
while the spec allowed the server to forget about an open_owner at any 
time there was no open state, in the case under discussion, that state 
had not in fact been forgotten.  It was argued that this it dubious for 
the server to act as if it had, despite the fact that an external 
observer, constrained to look at the data exchanged on the wire, would 
have no solid basis to impeach the server's choice.  The other issue 
concerns the validity of the proposed simple client's approach to 
management of open_owners.  This group relied on section 8.1.5 which 
requires seqids for a given owner to be ascending and argued that 
a client which did not maintain enough state to assure that was 
simply broken, arguing that this constraint could be accommodated 
relatively simply.  Although the specific details are too voluminous 
to be cited here, it was also argued that a client which reset the 
current seqid in this manner would break the at-most-once semantics 
that the sequencing logic was intended to secure. 

.

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