Subject: RE: [nfsv4] NFS4ERR_RESOURCE

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

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
the line.

The potential problem that we face is if clients issue COMPOUND's 
that the client implementor thinks are reasonable, which some
don't think are reasonable

-----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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 6 Jan 2004 11:00:26 -0500

> don't think are reasonable

The only way a client could recover from a RESOURCE error resulting from
a compound the server considers unreasonable would be to break up the
compound into simpler pieces and retry.  Does any client actually do
this?

It's a bit difficult to write an interoperable client if servers all
have different ideas of which compounds are reasonable and which
aren't.

--Bruce Fields

---

From: Mike Eisler <[email-masked]>
Date: Tue, 06 Jan 2004 12:55:14 -0800

> have different ideas of which compounds are reasonable and which

Given the good results from bakeoffs, only a bit difficult. Nonetheless,
it would be worthwhile if the NFSv4.1 doc (and the NFSv4.0 doc that
will be used for DRAFT standard status) provided a minimum "grammar"
that a server MUST support. E.g., the grammar might be:

COMPOUND :: COMP1 | COMP2 | SINGLETON

COMP1 :: PUT-OP , NEW-FH-OP , GETFH

COMP2 :: PUT-OP , SAME-FH-OP

SINGLETON :: RENEW | SETCLIENTID | SETCLIENTID_CONFIRM | ...

PUT-OP :: PUTFH | PUTROOTFH | PUTPUBFH
NEW-FH-OP :: LOOKUP | OPEN | ...

SAME-FH_OP :: OPEN_CONFIRM | READ | WRITE | ...

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 7 Jan 2004 18:06:34 -0500

On Tue, Jan 06, 2004 at 12:55:14PM -0800, Mike Eisler wrote:
> Given the good results from bakeoffs, only a bit difficult.

Sure, but I suppose we're all dealing with operating system interfaces
that break up filesystem operations into little pieces, and we're
probably also extending v2/v3 code, ending up as a result with compounds
that are very v2/v3-like.

If people started writing userspace programs that talked nfsv4, for
example, it's not hard to imagine they'd use longer compounds.  At which
point I think they could easily write an rfc-compliant nfsv4 client that
didn't in practice interoperate very widely.

> Nonetheless,
> that a server MUST support.

That would be helpful.--b.

---

From: Mike Eisler <[email-masked]>
Date: Thu, 08 Jan 2004 09:38:52 -0800

> that are very v2/v3-like.

Yes, I agree this is likely the case.

> didn't in practice interoperate very widely.

Only if you think that some of major server implementations (where
major can be defined as an implementation that shows up at an
interop event) return _RESOURCE in ways that
make it impossible for the client to recover. That may be the case.

Testing for it would be good. I don't know how easy it would be to
extend the existing synthetic clients. Where's Peter Astrand when we
need him. :-)

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Thu, 08 Jan 2004 12:53:29 -0500

> extend the existing synthetic clients. Where's Peter Astrand when we

i'll ask fred issaman (our new test guy) to look at it. he's been writing 
python tests...

-->Andy

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 8 Jan 2004 13:23:10 -0500

> make it impossible for the client to recover. That may be the case.

Also, there seems to be some confusion about how clients should recover.
That is, I'd thought _RESOURCE wouldn't usually be a transitory error,
and that it'd be used by, e.g., a server that never wants a setattr and
a read in the same compound.

But if people are designing clients to fail over to new servers when
they get _RESOURCE errors then apparently we don't all agree.

> extend the existing synthetic clients. Where's Peter Astrand when we

We've been continuing work on the Python nfsv4 code at citi.  We should
make a public release sometime.

--Bruce Fields