Subject: RE: [nfsv4] Mandatory

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 22 Jan 2004 09:20:25 -0800

> Note, though, that even replays of LOCK+WRITE+LOCKU are going to be fun
> to deal with, since they involve bumping the sequence number at least
> twice...

I haven't actually tried it but I think my server should deal with this
OK.  If you match on xid, you simply return the reply data from the
first execution without re-executing any of the state management code
(and note: no lease renewal).

What is much more fun (sort of, anyway) is LOCK+READ+LOCKU.  I think
I would return RESOURCE since read is one of those idempotent ops
that can return large amounts of data (too much for a reply cache)
while some of the ops are marked non-idempotent.  I guess I could
special-case something like this since the request as a whole is
idempotent.

The sessions proposal helps the replay situation by making detection
of replay reliable (no worry of xid's LRU-ing out of the table) but
we still have the issue of COMPOUND's that return large amounts
of data but which are not idempotent (or not recognizably idempotent).
My feeling is that we should tackle this issue in v4.1, by defining
clear rules for what are legitimate COMPOUND's, so that clients can
issue reasonably complicated COMPOUND's without having to worry 
about RESOURCE errors due to ill-understood server implementation
constraints, while servers are not asked to implement extremely
difficult reply storage logic to support arbitrarily complicated
COMPOUND's. 

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]]
Sent: Thursday, January 22, 2004 11:54 AM
To: J. Bruce Fields
Cc: Noveck, Dave; [email-masked]; Stevan Steve Allen;
[email-masked]
Subject: Re: [nfsv4] Mandatory

På to , 22/01/2004 klokka 11:42, skreiv J. Bruce Fields:
> This would make the RESOURCE error recovery problems a bit more
> pressing, since the way most servers are written now I get the
> impression they'd be likely to return RESOURCE if you tried something
> that complicated.

No existing servers have implemented Dave's proposal. This is a future
extension.

Note, though, that even replays of LOCK+WRITE+LOCKU are going to be fun
to deal with, since they involve bumping the sequence number at least
twice...

Cheers,
  Trond

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

---

From: Brent Callaghan <[email-masked]>
Date: Thu, 22 Jan 2004 11:02:19 -0800

COMPOUNDs were supposed to allow clients to assemble NFS calls
tailored more precisely to their needs, i.e. a Java client with
a different API might use a quite different set of COMPOUNDs than
a Linux kernel client.  There was also a (perhaps) naive hope that
in building the protocol from a simple set of primitives, we could
actually make it simpler (heh).  The expectation that COMPOUNDs might
accomplish more on the server per RPC call was secondary.

However, many protocol features later conflicted with the purpose
of COMPOUND such as: OPEN, stateids, non-atomicity, and RESOURCE
errors.  Also, now that the protocol is so semantically heavy, I
doubt it will be interesting to those non-UNIX, non-Windows
clients and servers that may want to use COMPOUND in novel ways.

The protocol, with its current semantics, would likely be
simpler without COMPOUND.  Case in point: the DAFS protocol
retained many of the NFSv4 semantics, but did away with
COMPOUND.

	Brent