Subject: RE: [nfsv4] NFS4ERR_RESOURCE

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 6 Jan 2004 08:08:26 -0800

Previous send inadvertent.  Complete message follows.

Attempting failover suggests that the resource issue is load-
related.  A lot of the discussion of returning RESOURCE is about
conditions related to the complexity of the COMPOUND, when 
measured against the server implementor's standard of 
reasonableness, in which the server implementor, deciding
that it is just not possible to handle all possible COMPOUNDS's,
has to draw the line somewhere, since the spec doesn't draw
such a line.

The potential problem that we face is that if clients issue 
COMPOUND's that the client implementor thinks are reasonable, 
which some servers don't think are reasonable, then doing
failover and delay-retry are not going to work; you have to 
cut down the request.  The good news is that so far, we haven't 
faced that issue in interoperability testing (everything that
clients issue, servers think is reasonable).  Unfortunately, 
that's also the bad news, in that client handling of this
situation is not getting testing.

I think we need servers at Connectathon that optionally 
take a very harsh line on what is a reasonable COMPOUND as
a way of testing that clients are able to deal properly
with RESOURCE errors.  Such servers should obey Mike's
restrictions on avoiding RESOURCE on GETFH after an
operation that changes the current filehandle.  I'm putting
this on Connectathon to-do list, but I'm not saying where 
on the list it will wind up.

BTW, one class of RESOURCE errors that the Netapp server
hands out hasn't been mentioned.  That is a case in which
the structure of the COMPOUND makes it impossible to 
reasonably store the information in the reply cache.
The issue is READ (and other ops that return lots of data)
within non-idempotent requests.  The issue is that in v2/v3
requests either return small amounts of data, or are
idempotent (or both).  No request can return a large 
amount of data and be non-idempotent.  In v4, you can have
READ which is an idempotent op as part of a non-idempotent
request.  You can have READ followed by WRITE or READ
followed by REMOVE, and in those kinds of cases we return
RESOURCE.  So far, all complaints about that have been in
the abstract.  We have not run into a client that actually 
issues such requests. 

-----Original Message-----
From: Eric Kustarz [mailto:[email-masked]]
Sent: Monday, January 05, 2004 7:39 PM
To: Mike Eisler
Cc: [email-masked]
Subject: Re: [nfsv4] NFS4ERR_RESOURCE

>
>
> A question to client implementors is whether they handle
> _RESOURCE?

The Solaris client currently handles this error (will attempt failover 
if replicas specified at mount time, otherwise delay and retry).  We 
also don't bump the seqid as RESOURCE is one of the seven non-bumpers.

eric

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

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

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