Subject: Re: [nfsv4] Capturing my items from Toronto

From: "Matt W. Benjamin" <[email-masked]>
Date: Thu, 7 Aug 2014 19:35:10 -0400 (EDT)

Hi,

Thanks for the summary.

----- "Tom Haynes" <[email-masked]> wrote:

> Beepy asked us to summarize our presentations, objections, and AIs for
> the WG/chairs.

> 
> 1) Some work still to finish from Andy’s presentations.
> 2) Need to document what we plan to do for object label changes (I.e.,
> nothing)
> (Note, slides already modified to show object and not subject! Thanks
> David!)
> 3) Need to add text for LAYOUT_STATS to not be dependent on layouts.
> 
> Pranoop: Wants to know how we can capture STATS generically.
> Matt: Wants the blob back in there.

Yes, although I actually prefer Tom's original LAYOUTUPDATE proposal for this
reason (avoids suggesting semantics which may not be general).

> 
> 
> Flex Files:
> 
> Asked to be a WG document: implementation experience and focused
> text.
> 
> Spencer asked who else supported this?
> Matt said that he supported it. But, Matt would also like to see it go
> back to being striped.

Our Ceph files layout uses striping.  The Flex Files layout solves our device
management problem, but loss of striping would be unfortunate.

Matt

-- 
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: Tom Haynes <[email-masked]>
Date: Thu, 21 Aug 2014 14:23:46 -0400

> reason (avoids suggesting semantics which may not be general).

Hi Matt,

Are you mixing up LAYOUTSTATS with LAYOUTERROR?

I.e., LAYOUTSTATS is:

16.7.1.  ARGUMENT

   struct layoutupdate4 {
           layouttype4             lou_type;
           opaque                  lou_body<>;
   };

   struct io_info4 {
           uint32_t        ii_count;
           uint64_t        ii_bytes;
   };

   struct LAYOUTSTATS4args {
           /* CURRENT_FH: file */
           offset4                 lsa_offset;
           length4                 lsa_length;
           stateid4                lsa_stateid;
           io_info4                lsa_read;
           io_info4                lsa_write;
           layoutupdate4           lsa_layoutupdate;
   };

which has a blob. Whereas LAYOUTERROR does not:

16.6.1.  ARGUMENT

   struct device_error4 {
           deviceid4       de_deviceid;
           nfsstat4        de_status;
           nfs_opnum4      de_opnum;
   };

   struct LAYOUTERROR4args {
           /* CURRENT_FH: file */
           offset4                 lea_offset;
           length4                 lea_length;
           stateid4                lea_stateid;
           device_error4           lea_errors;
   };

The reason LAYOUTERROR does not need one is that in the context of LAYOUTRETURN it is already part of a blob. Further, it is the responsibility of the client to map storage device errors to NFSv4 errors. I.e., the mapping layer removes the need for a blob.

---

From: "Matt W. Benjamin" <[email-masked]>
Date: Thu, 21 Aug 2014 14:33:22 -0400 (EDT)

Hi,

I'm certainly being dense here, but what of layout types for which there is no useful mapping?  More importantly, why is any mapping useful, when the server endpoints indirectly communicating are assured to share (via the layout type) a native dialect?

Matt

----- "Tom Haynes" <[email-masked]> wrote:

> The reason LAYOUTERROR does not need one is that in the context of
> LAYOUTRETURN it is already part of a blob. Further, it is the
> responsibility of the client to map storage device errors to NFSv4
> errors. I.e., the mapping layer removes the need for a blob.

http://linuxbox.com

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

---

From: Tom Haynes <[email-masked]>
Date: Thu, 21 Aug 2014 14:49:36 -0400

On Aug 21, 2014, at 2:33 PM, Matt W. Benjamin <[email-masked]> wrote:

> Hi,
> 
> I'm certainly being dense here, but what of layout types for which there is no useful mapping?

NFS4ERR_SERVERFAULT ?

The errors being reported are between the client and the storage device (which is over a given protocol). The only errors that can be reported are ones that the MDS can use to fix something on the storage device. Where fix may mean “no longer advertise that storage device in the layout”.

>  More importantly, why is any mapping useful, when the server endpoints indirectly communicating are assured to share (via the layout type) a native dialect?
> 

In the context of flexible files, we define loosely and tightly coupled servers. Your question assumes tightly coupled, but even in that scenario there is no such assurance. Go look at 5664 for an existing example - look at Section 8.1.

---

From: Tom Haynes <[email-masked]>
Date: Thu, 21 Aug 2014 15:05:38 -0400

Hi Matt,

BTW - here is the earlier thread on why we are this choice:

https://www.ietf.org/mail-archive/web/nfsv4/current/msg13020.html

Thanks,
Tom

On Aug 21, 2014, at 2:49 PM, Tom Haynes <[email-masked]> wrote:

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