Subject: Re: [nfsv4] LAYOUTERROR vs LAYOUTSTATS [was Re: Capturing my items from Toronto]

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

Hi Tom,

Thanks for the pointer.  I'm unsure about the reasoning here.

First, while the protocol over which the operations being performed may not be uniquely determined by the layout (in the case of some layout types), the set of possible protocols is so determined, and can be read off the layout.  Whatever protocol the client is using to communicate with a DS, the MDS can be expected to understand its error dialect.

The problem with "just return SERVERFAULT" is that it is just losing the interesting information.  We would agree that needing to define allowed error returns is an undesirable feature of earlier layout drafts (it's lossy, and terrible from a future-proofing perspective).  The opaque error return option seems like the ideal resolution, since no error mappings are required at all in that approach.

Matt

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

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