Subject: RE: NFS4ERR_BADHANDLE

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 27 Nov 2001 09:54:27 -0800

There's an analogous situation that was discussed with regard
to NFS4ERR_STALE, which is also listed as an error under
PUTFH and also under the oeprations that actually use the 
handle.

Although I haven't looked for the actual e-mail, my memory
is that we decided that a server was not obliged to check
the handle for staleness at PUTFH time.  It could do so
if it wished but it could also not check and leave it until
the handle was actually used.  I think that choice was
based on the following considerations:

     Since COMPOUND is not atomic, even if a check were 
     required at PUTFH time, a file handle could still
     become stale during the processing so NFS4ERR_STALE
     would have to be a valid error for the operations
     that actually used the file handle.

     Given that, clients would have to be prepared for
     NFS4ERR_STALE returned from the ops that use the
     file handle, in any case, and thus not depend on
     a check at PUTFH time.

     Since some servers would have to do the check for 
     staleness during the operations that used the file 
     handle, requiring them to do it as well for the
     PUTFH is a waste of cycles, especially since the
     client would derive no benfit.

     On the other hand, some servers might be implemented
     so that COMPOUND is handled atomically (atomicity
     isn't required but it may be a feature of particular
     implementations) in which case, a file handle check
     at PUTFH would serve the purpose and be more efficient,
     so servers are allowed to do the check at this point.

For NFS4ERR_BADHANDLE, most of that doesn't apply.  Handles
can't become bad in the middle of a COMPOUND, so we could
require that this check be made at PUTFH time and remove
the errors from the point of use.  Or we could handle
BADHANDLE like STALE and give servers their choice about
when they wanted to check for this. 

-----Original Message-----
From: Peter Åstrand [mailto:[email-masked]]
Sent: Tuesday, November 27, 2001 10:05 AM
To: [email-masked]
Subject: NFS4ERR_BADHANDLE

The spec says ACCESS, and most other operations, can return
NFS4ERR_BADHANDLE. When does this happen? I suppose this means that the
current filehandle (cfh) is BAD. How can that happen, when it's not
possible to PUTFH a BAD FH?

-- 
Peter Åstrand                Telephone: +46-13-21 46 00
Cendio Systems               E-mail: [email-masked]
Teknikringen 3
583 30 Linköping
Sweden

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 27 Nov 2001 12:32:23 -0600

On Tue, Noveck, Dave wrote:

<snip>

> when they wanted to check for this. 

I prefer that we leave this to implementation choice.  The advantage
of requiring the check at PUTFH doesn't seem necessary since the
client needs to deal with STALE errors already for the reasons you
have provided.

Spencer

---

From: Peter Åstrand <[email-masked]>
Date: Wed, 28 Nov 2001 10:34:48 +0100 (CET)

> client needs to deal with STALE errors already for the reasons you

Thanks for good explanations. My preferences would be to require the check
to be done at PUTFH time only. Limiting the number of possible errors is a
good thing, IMHO. Allowing NFS4ERR_BADHANDLE for 20 operations or so just
with the motivation that NFS4ERR_STALE can occur, which is similiar,
sounds strange.

If the spec. does not specify if PUTFH should return NFS4ERR_BADHANDLE or 
not for a BAD handle, this makes testing harder. I have to distinguish 
between two types of implementations:

1) With implementations that does the check at PUTFH time, it's sufficient
with one single testcase to trigger NFS4ERR_BADHANDLE. 

2) With implementations that does the check later, on some other 
operation, I have to write testcases for each of those operations which 
can return NFS4ERR_BADHANDLE. This means something like 20 testcases. 

I also have to write code to distinguish between these two types of
implementations and since test cases should not depend on each other, the
check for which type if implementation we are testing has to be done at
every of these 20 operations that can return NFS4ERR_BADHANDLE. Not
pretty.

In general, I think the protocol should be always "deterministic", unless
there is a good reason for it not to be. For NFS4ERR_STALE, there is a
reason for leaving the behaviour as an implementation choice[1], but I
cannot clearly see the advantage of not defining when the check for
NFS4ERR_BADHANDLE should be done.

([1]: I actually would prefer that NFS4ERR_STALE would be removed from
PUTFH also, ie that PUTFH should not check for stale fh:s. The performance
gain for allowing the check to be done at PUTFH instead of at operation
time will probably be small. And wouldn't it be possible for servers to
internally do the check at PUTFH time, save the result, but not returning
it until some operation is trying to use it?)