Subject: RE: Spec-related discussions at the Bake-off

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 1 Nov 2000 20:35:28 -0800

>> 1a) Don't increment seq-id on error

> Keep in mind the stateid can change with every request (that's why it is
> returned), and that all requests that take a seqid also take a
> stateid. 

Except for OPEN.

> Thus if client increments the seqid, what stateid would it use?

The stateid that is appropriate which is the one it got back in the
non-error case and the current one (unchanged) in the error case
since no new stateid is returned in the error case.
 
> The previous stateid is valid only with seqid X, not X+1. So that's
> why we don't increment the seq-id on error.

I don't understand your point.  

>> 1c) Remembrance of state-id's past
>> 
>> During the discussion of item 1, Dave brought up the issue of a
>> retransmitted CLOSE. To respond correctly, it is necessary to compare
>> the sequence id to the sequence id for the lockowner. This necessitates
>> knowing the lockowner. The problem is that the lockowner can only be
>> found using the stateid passed in the CLOSE. If the CLOSE succeeded,
>> then you would expect the state entry to be deallocated, which means
>> that you would get a BAD_STATEID error and the server will be unable to
>> find the lockowner necessary to treat this as a duplicate.

> A stateid is associated with an nfs_lockowner, not an open
> file. If there are multiple open files associated with the
> nfs_lockowner, then removing the nfs_lockowner is not allowed.

Well there is some difference of opinion on this.  My understanding
is that it designates a given lockowner-file pair.  I think I got this
impression in a discussion with Robinson, but at this point I can't
be sure.  Anyway, this is the way my server is implemented.

I could change thing if we decide that is the right way to do 
things.  One worry about doing it this way is it increases the
chances of running into an OLD_STATEID error sicne a lock and
an IO will conclict even if they are on different files.

There is some stuff in the spec that refers to it as designating a
lockowner-file pair, which I think I wrote.

Thinking about Item 15, Hummingbird's problem with multiple opens,
the stateid=lockowner would be even further from what they need,
even though stateid=lockowner+file isn't enough for them either.
They indeed want (they say need) stateid=open-file.

> If this is the last open file associated with the nfs_lockowner, then
> there are issues, which are discussed in section 8.1.7 of the i-d.
> In a nutshell, removing an nfs_lockowner before a time period
> corresponding to the lease time is not advisable.

Gievn stateid=lockowner, yes, although I don't see why the timeout
is necessarily the lease time.

>> 2) Response count for COMPOUND
>> There was some confusion about the op count in the response
>> for COMPOUND. If the final op has an error, is that
>> included? While the consensus was that the right answer is,
>> "Yes.", the fact that this has come up, suggests that the
>> spec should be made clearer on this issue.
>
> Section 13.2 says:
>
>  The results of each operation are preceded by the opcode and
>  a status code (normally zero).  If an operation results in a non-zero
>  status code, the status will be encoded and evaluation of the
>  compound sequence will halt and the reply will be returned.
>
> Section 14.2 says:
>
>     [...] The
>     results for all of the evaluated operations must be returned to the
>     client.
> [...]
>     Contained within the COMPOUND results is a "status" field.  If the
>     results array length is non-zero, this status must be equivalent to
>     the status of the last operation that was executed within the
>     COMPOUND procedure.  Therefore, if an operation incurred an error
>     then the "status" value will be the same error value as is being
>     returned for the operation that failed.
>     
> IMHO, it's clear.

Always seemed clear to me, but since this has come up (more than once, I 
think), maybe it isn't clear enough.

>> 4) Lease and deadlocks
>> 
>> There was some concerns expressed about leases in a situation in which
>> a given lockowner obtained a lock and then hung. If other processes
>> continued unaffected then the leases associated with the locks held by
>> the lockowner would be periodically renewed, even when, it could be
>> argued, they shouldn't be.
>> 
>> The general consensus was that this behavior was inherent in the lease
>> design and that it was the responsibility of the client operating
>> system to deal with, but perhaps the spec should discuss this issue.
>
> This seems like a discussion that belongs to forthcoming implementation
> i-d.

OK with me.

>> 5) CREATE/OPEN/MKDIR errors
>
>> Sergei pointed out that when OPEN-create which encounters a
>> directory with the target name, the spec does not provide
>> for an informative error code. NFS4ERR_EXISTS doesn't
>> really tell the client what happened. A separate
> 
> This is reasonable. There's plenty of whitespace in the error section
> of OPEN to add NFS4ERR_ISDIR when and if the rfc editor gives
> the authors the 48 hour window to make final edits.
> 
>> NFS4ERR_ISDIR would be better. Similarly when a CREATE of a
>> directory encounters a file whose type is not a directory.
>
> what operating environment would use this code?

Don't know.  Sergei?

> for example, on my Solaris desk top, I get:

> frostback% touch a
> frostback% mkdir a
> mkdir: Failed to make directory "a"; File exists

>> 6) Server references delegations by FH, not stateid
>> 7) TAG, what's it good for?

> Is there a proposal to alter version 4.0 of spec, already
> approved by iesg, with publication imminent? This amounts
> asking iesg to reverse its decision.

Don't know about all this IETF esoterica.  I thought it was
a Proposed Standard, but that changes could be made, based on
implementation experience, after Proposed Standard on the 
way to it becoming a Draft Standard.

> So how important are these issues to the bake off crowd?

Speaking personally, the fact that the tag is a waste can
be mostly dealt with (except the last four bytes) by clients
simply sending zero-length tags (and if some document is to
say this, this could be the implementation RFC).  The other
problem about tags, is that some servers change (lengthen)
the tag sent to them before returning it making it difficult 
for some clients to get page-aligned directory data in their 
cache.  I suppose peer-pressure can probably deal with this 
issue.

Getting rid of the last four bytes would only be worth it if
we are changing the spec for other reasons.  Otherwise we
can leave it as "an experiment noble in purpose."

>> 10) Initial sequence id
>
>> In the case in which the server is requiring confirmation,
>> it is pretty clear that any value presented by the client
>> is OK, but what about the case in which no confirmation is
>> required?

> Since it's ok for the client to use any seqid when the server
> requires confirmation, and since the client has no
> idea if the server requires confirmation, it follows that
> any value is permissable.

OK.

>> 16) Stateid returned on CLOSE. Why?
>
>> There seems to be no valid use for the stateid returned on
>> CLOSE, since the file is no longer opened by that
>> lockowner. What is it there for?

> Stateids are per nfs_lockowner not per open file.  Thus the CLOSE
> causes the sequence number to be incremented on the server's and
> client's nfs_lockowner state structure.  The new stateid is used on the next
> operation that takes the stateid, and so, the seqid and stateid better
> match what the server expects.

Most likely you are going to do an OPEN with doesn't take a stateid
but I see how this would work given stateid=lockowner.

>> 18) Unlimited-length opaques. Just say "No"?

>> Andy points out that there are a number of unlimited-length
>> opaques in the protocol (e.g. client-string, lockowner) and
>> that each each such adds to server vulnerabilities to
>> denial-of-service attacks. The possibility of a 32 kbyte
>> lockowners appearing makes coding of the server more
>> complicated and will hurt performance in the normal case,
>> unless great efforts are made to optimize server
>> performance.
>
> The danger with setting limits now is that the selections
> will be to low.

That is a danger but you accept (below) that there have to be 
limits.

> Again, do we want to ask iesg to rescind approval?

I suppose not.

> Keep in mind that that this issue exists already in the
> record marking header that prefixes every rpc message.  If
> there is a 32 kbyte nfs lockowner, then over TCP, the
> record marking lengths will sum to over 32 kb. Implementors
> *are* making sure that the record marking length is
> reasonable before further processing right?

> Thus, TCP is your friend.

> If using UDP, and if unreasonable (as compared to tunable
> values) lengths are passed, why not return an error or
> treat it as an XDR decode error, and log it in the
> implementation. Since the limits will be tunable, they can
> be upped if necessary. Practically speaking,
> implementors will select limits that work in most cases, because
> they've tested with each other.

I don't see why it is better for everybody to choose their
own limits and expect them to interoperate most of the time,
after some level of testing, than to agree on reasonable
limits and follow them.  Why is it better to return an
error (which?) for something the spec says is not an error 
or to return an XDR decode error for something that the .x
file says is perfectly OK.

Asking customers to tune various variables when they get 
XDR errors, is job security for somebody, but it doesn't
really make sense.

Given that it appears that avoiding another trip through the
buracracy trumps all other considerations, I guess we can
just live with the problem.

---

From: Carl Beame <[email-masked]>
Date: 02 Nov 2000 11:51:09 +0000

> just live with the problem.

The problem of Open upgrade and Open downgrade/ close being closeall
is an issue which makes the NFS server on NT not an advisable solution
since these functions CANNOT be implemented properly. The at the
bake-off was that there was no NEED for these functions. 
What now, given the above ?????

- Carl