Subject: Re: [nfsv4] [PATCH] No reason for LAYOUTERROR to have an opaque payload

From: "Matt W. Benjamin" <[email-masked]>
Date: Wed, 11 Jun 2014 10:47:21 -0400 (EDT)

Hi,

Shouldn't all layout operations have opaque data for future proofing/consistency?  (Probably the payload would not be a layoutupdate4, though, since it should be op-specific.)

Matt

----- "Benny Halevy" <[email-masked]> wrote:

> On 06/10/2014 11:30 AM, Thomas Haynes wrote:
> > From: Tom Haynes <[email-masked]>
> > 
> > When the error code was handled in the layout return, we needed the
> > opaque payload to allow for the different layout types to specify
> > their own payloads.
> > 
> > As we now have our own procedure, there is no need for an opaque
> > payload.
> > 
> > Signed-off-by: Tom Haynes <[email-masked]>
> 
> Makes sense.
> 
> Benny
> 
> > ---
> >  nfsv42_middle_op_layouterror.xml | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/nfsv42_middle_op_layouterror.xml
> b/nfsv42_middle_op_layouterror.xml
> > index 526be06..688fde0 100644
> > --- a/nfsv42_middle_op_layouterror.xml
> > +++ b/nfsv42_middle_op_layouterror.xml
> > @@ -3,7 +3,6 @@
> >  
> >  <section anchor='op:layouterror' title='Operation 64: LAYOUTERROR -
> Provide Errors for the Layout'>
> >    <section toc='exclude' title="ARGUMENT">
> > -    <?rfc include='autogen/type_layoutupdate4.xml'?>
> >      <?rfc include='autogen/type_device_error.xml'?>
> >      <?rfc include='autogen/layouterror_args.xml'?>
> >    </section>
> > 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

-- 
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel.  734-761-4689 
fax.  734-769-8938 
cel.  734-216-5309

---

From: Benny Halevy <[email-masked]>
Date: Wed, 11 Jun 2014 10:57:29 -0400

On Wed, Jun 11, 2014 at 10:47 AM, Matt W. Benjamin <[email-masked]>
wrote:

> Hi,
>
> Shouldn't all layout operations have opaque data for future
> proofing/consistency?  (Probably the payload would not be a layoutupdate4,
> though, since it should be op-specific.)
>

I don't think general extensibility of all operations is necessarily good.
We have layout-type specific payload work it makes sense and we can define
its logical semantics at the generic layer.

Benny

---

From: "Matt W. Benjamin" <[email-masked]>
Date: Wed, 11 Jun 2014 11:13:29 -0400 (EDT)

Hi Benny,

If it's generically valid for an implementation
to return errors, how do we know it will not be useful to provide layout-type
specific detail?  The intended semantics of the general operation may be clear,
but the supporting detail better left to the layout.

Matt

----- "Benny Halevy" <[email-masked]> wrote:

> On Wed, Jun 11, 2014 at 10:47 AM, Matt W. Benjamin < [email-masked]
> > wrote:
> 
> 
> Hi,
> 
> proofing/consistency? (Probably the payload would not be a
> layoutupdate4, though, since it should be op-specific.)
> 
> 
> 
> We have layout-type specific payload work it makes sense and we can
> define its logical semantics at the generic layer.
> 
> 
> 
> Benny
> 
> 
> 
> 
> Matt
> 
> 
> 
> ----- "Benny Halevy" < [email-masked] > wrote:
> 
> > > From: Tom Haynes < [email-masked] >
> > >
> > > Signed-off-by: Tom Haynes < [email-masked] >
> >
> > Makes sense.
> >
> > Benny
> >
> > > ---

http://linuxbox.com

tel.  734-761-4689 
fax.  734-769-8938 
cel.  734-216-5309