Subject: RE: [nfsv4] re: more on server cache

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 19 Nov 2003 06:00:11 -0800

> > Currently in such a sitation our server returns a RESOURCE error. I
> > believe the spec allows that. This is what the spec says about that:
> 
> I'd be interested in hearing what others (particularily client writers)
> have to say. My fear would be that clients don't know what to do when they
> get NFS4ERR_RESOURCE, except maybe EIO to the process.

So far, it hasn't been an issue because clients have not done the kind of
insane (perhaps I should be politically correct and call them "interesting")
COMPOUNDs that would trigger this.  I agree that clients have probably 
not invested any effort in recovering from NFS4ERR_RESOURCE, but that is
because they don't do the kind of COMPOUNDs that would prompt it.  If
clients start to do those kinds of COMPOUNDs, they are going to have to
invest in that sort of recovery or else not work with a large class of
servers.  Most everybody is going to have difficulty trying to handle
the reply caching for a large READDIR followed by a CREATE, for example.

> As such, I haven't
> used it and wouldn't want to for the cache case, since not being able to
> cache the reply is not going to affect correct operation 99.9% (or more?)
> of the time. 

I disagree 100% (or at least 99.9% :-).  The problem with the argument that
the retry case is only .1% is that if you accept the request (and don't return
NFS4ERR_RESOURCE), you are saying you can handle the request.  If you have a
reply cache, and we all do, part of processing the request is dealing with
retries.  So you are encouraging the client to do something that will cause
him to come to grief.  True, it is only a small fraction of the times, but if
you accept a request of that form, the client will do lots of them, so that
.1% (or whatever it is) will be a non-null set of instances in which you
will do a retry and get something that is not correct.  It is better to tell
the client up-front that you can't do the operation.  If there were some way
to tell the client that you would do the request once, but if he were 
subsequently to do a retry, it would fail, then he could make a judgment 
and decide what to do.  But there isn't.  The only thing you can do is to
promise him that everything will be processed correctly (with your fingers
crossed) or be honest and say you can't do it.   

> I see it as a reply when the server just can't continue and
> uses it to satisfy the "must reply to every compound RPC" rule?

I would say "just can't continue correctly".

> Anyhow, we'll see what others think, rick

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