Re: [nfsv4] rfc5667bis open issues

[David Noveck <[e-mail]>]

> Does this count as a dropped RPC reply, such that an NFSv4 server
> would have to drop the connection?

I don't see any reason why it should.  Apart from RPC-over-RDMA, does this
apply to other XDR decode issues on the server? After all, it is getting a
reply, even if the content is essentially "I don't understand the request."

> When an NFS server returns one of these responses, does it
> have to enter the reply in its DRC ?

I should hope not.  The purpose of the DRC is to prevent repeated execution
of non-idempotent requests.  A request that you can't decode does not
change any state on the server.

> What if any implications are there for an NFSv4.1 session
> (slot retired? ignored?)

Why does this have to have to be addressed in 5667bis?  I don't see why XDR
decode errors need to be addressed differently in the RPC-over-RDMA case.

> The current text of rfc5666bis (Section 5.3.2) suggests that when
> multiple Write chunks are provided for an RPC, and the responder
> doesn't use one of them, it should use that chunk for the next
> DDP-eligible XDR data item.

It does say that and the treatment there is limited to the case of multiple
write chunks.  The treatment for the analogous case when there is a single
write chunk is addressed in 4.4.6.2.  Th treatment is the same:  each
DDP-eligible item is matched with the first available write chunk until
either there are no more write chunks or no more DDP-eligible items in the
reply.

> The problematic text is actually this part of rfc5666bis:

I don't see why this is described as "problematic".  Is there a suggestion
that we might change this text to something less problematic?  I don't see
how to do that.  I believe we should leave the text as it is.

Within Version One, there is no way to tie write chunks to particular
DDP-eligible items.  While one might think of that as a problem it is not
one that can be addressed in Version One or in rfc5667bis.


On Thu, Sep 22, 2016 at 6:36 PM, Chuck Lever <[e-mail]> wrote:

>
> > On Sep 22, 2016, at 3:10 PM, Chuck Lever <[e-mail]> wrote:
> >
> > I'm preparing a new revision of rfc5667bis, and a couple of issues have
> > arisen:
> >
> > 1. Reporting RPC-over-RDMA decoding errors on NFSv4
> >
> > The current text says the NFS server can return an RPC GARBAGE_ARGS
> > reply, or an RPC-over-RDMA level ERR_CHUNK reply.
> >
> > Does this count as a dropped RPC reply, such that an NFSv4 server
> > would have to drop the connection?
> >
> > When an NFS server returns one of these responses, does it have to
> > enter the reply in its DRC ? What if any implications are there for
> > an NFSv4.1 session (slot retired? ignored?)
> >
> >
> > 2. Skipping Write chunks in an NFSv4 COMPOUND
> >
> > The current text of rfc5666bis (Section 5.3.2) suggests that when
> > multiple Write chunks are provided for an RPC, and the responder
> > doesn't use one of them, it should use that chunk for the next
> > DDP-eligible XDR data item.
>
> The problematic text is actually this part of rfc5666bis:
>
> 4.4.6.2.  Unused Write Chunks
>
>    There are occasions when a requester provides a Write chunk but the
>    responder is not able to use it.
>
>    For example, an Upper Layer Protocol may define a union result where
>    some arms of the union contain a DDP-eligible data item while other
>    arms do not.  The responder is REQUIRED to use requester-provided
>    Write chunks in this case, but if the responder returns a result that
>    uses an arm of the union that has no DDP-eligible data item, the
>    Write chunk remains unconsumed.
>
>    If there is a subsequent DDP-eligible data item, it MUST be placed in
>    that unconsumed Write chunk.  The requester MUST provision each Write
>    chunk so it can be filled with the largest DDP-eligible data item
>    that can be placed in it.
>
>
> > This could be a problem for READ_PLUS. The client has no way of
> > predicting whether the server will return a CONTENT_DATA arm (which
> > would consume a Write chunk) or a CONTENT_HOLE arm (which would not).
> >
> > I think a better approach would be for the binding to specify that
> > if a Write chunk is provided for a READ_PLUS operation, the server
> > consumes that chunk:
> >
> > - by returning CONTENT_DATA in that chunk
> >
> > - by returning an empty chunk for CONTENT_HOLE
> >
> > If the client provides an empty chunk in that position, the
> > READ_PLUS result is returned inline.
> >
> > Opinions?
>
> --
> Chuck Lever
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>