Return-Path: <thomas.haynes@primarydata.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 0A1BC1A02E6
 for <nfsv4@ietfa.amsl.com>; Fri, 16 May 2014 08:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7]
 autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ENOLbP5XjBhi for <nfsv4@ietfa.amsl.com>;
 Fri, 16 May 2014 08:43:27 -0700 (PDT)
Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com
 [209.85.220.43])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 274A81A0283
 for <nfsv4@ietf.org>; Fri, 16 May 2014 08:43:27 -0700 (PDT)
Received: by mail-pa0-f43.google.com with SMTP id hz1so2717095pad.30
 for <nfsv4@ietf.org>; Fri, 16 May 2014 08:43:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:content-type:mime-version:subject:from
 :in-reply-to:date:cc:message-id:references:to;
 bh=aobmPwfoEwZuDoWmOgw80+7cUQPdZvINyN3KjUbgx5E=;
 b=DS8d4S/d84juzyDP3m/XDvloE8yizeZ2VH/VhyQYKyrW2xB8l8wYaBY+8JqSduFKPK
 EvQPm7ABkKvWQBP93zadOWl4sdBHamKrvqZtbHrXSBvgJRIh5ShcKoJa7lKRfFURER3p
 5OstDpNzPdU0IrYoyq+XlxnYdL0ABTVUPnhQEPzQDTmuScbBy5dWrTBZ4l+3sxokwRHM
 UJ4p8BDmYlIp+8Wh5Tjr7YsyEJg9PaZs8M3c2x+0w171y1G8oFGZjga0YAO9VnoSe/h7
 axlzrpws+9PYqStySVv0IhXIzoMlNJWqXj2yO8fvy8LhsJzOazVJDYVzzs/w7JNqd40b
 Sk4g==
X-Gm-Message-State: ALoCoQm4zMXYW8vd2nDi4RdVHiwe/EFUKXOKEJnsZyILRYZ2K5d0HpL2GrUHrOM2jaa2OslbkfY1
X-Received: by 10.69.19.225 with SMTP id gx1mr22183042pbd.34.1400254999776;
 Fri, 16 May 2014 08:43:19 -0700 (PDT)
Received: from [192.168.2.10] (ip98-184-165-70.tu.ok.cox.net. [98.184.165.70])
 by mx.google.com with ESMTPSA id
 gj9sm15201945pbc.7.2014.05.16.08.43.18 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Fri, 16 May 2014 08:43:19 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_F47D922A-BF96-4FA7-AB4F-697134D692E0"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Tom Haynes <thomas.haynes@primarydata.com>
In-Reply-To: <20140516082328.GB25772@lst.de>
Date: Fri, 16 May 2014 10:43:15 -0500
Message-Id: <A4002329-DFFB-4520-BD79-A5617E2F68FF@primarydata.com>
References: <1400201769-40352-1-git-send-email-Thomas.Haynes@primarydata.com>
 <1400201769-40352-3-git-send-email-Thomas.Haynes@primarydata.com>
 <20140516082328.GB25772@lst.de>
To: Christoph Hellwig <hch@lst.de>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/nfsv4/uA8pEo1P0M2Wsve_tt4XeMtazgg
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] [PATCH 2/3] Morph LAYOUTRETURN errors into LAYOUTERROR
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>,
 <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>,
 <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 May 2014 15:43:38 -0000


--Apple-Mail=_F47D922A-BF96-4FA7-AB4F-697134D692E0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii


On May 16, 2014, at 3:23 AM, Christoph Hellwig <hch@lst.de> wrote:

>> +    <t>
>> +      Each individual device_error4 describes a single error
>> +      associated with a storage device, which is identified via
>> +      de_deviceid.  The operation which returned the error is
>> +      identified via de_opnum. Finally the NFS error value (nfsstat4)
>> +      encountered is provided via de_status and may consist of the
>> +      following error codes:
> 
> What would the client put into de_opnum for block or object layouts?
> 

The allowable storage device ops are the data-server housekeeping
and data-server I/O operations. A Layout Type like Flex Files can
report on the housekeeping ones. For the Block or Object Layout Types,
those ops would not make sense.

So everything else comes back to COMMIT, READ, WRITE, and PUTFH.

Are there any other ops used for block or object layout drivers?

And the spec could define that if the de_opnum is ILLEGAL, it
signifies that it was a driver specific operation.

The other question is whether the client is mapping errors to nfsstat4 or
using something like:

   /// enum pnfs_osd_errno4 {
   ///     PNFS_OSD_ERR_EIO            = 1,
   ///     PNFS_OSD_ERR_NOT_FOUND      = 2,
   ///     PNFS_OSD_ERR_NO_SPACE       = 3,
   ///     PNFS_OSD_ERR_BAD_CRED       = 4,
   ///     PNFS_OSD_ERR_NO_ACCESS      = 5,
   ///     PNFS_OSD_ERR_UNREACHABLE    = 6,
   ///     PNFS_OSD_ERR_RESOURCE       = 7
   /// };
I think the client should do the mapping. 
--Apple-Mail=_F47D922A-BF96-4FA7-AB4F-697134D692E0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On May 16, 2014, at 3:23 AM, Christoph =
Hellwig &lt;<a href=3D"mailto:hch@lst.de">hch@lst.de</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><blockquote type=3D"cite">+ =
&nbsp;&nbsp;&nbsp;&lt;t&gt;<br>+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Each =
individual device_error4 describes a single error<br>+ =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;associated with a storage device, which is =
identified via<br>+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;de_deviceid. &nbsp;The =
operation which returned the error is<br>+ =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;identified via de_opnum. Finally the NFS =
error value (nfsstat4)<br>+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;encountered is =
provided via de_status and may consist of the<br>+ =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;following error =
codes:<br></blockquote><br>What would the client put into de_opnum for =
block or object layouts?<br><br></blockquote></div><br><div>The =
allowable storage device ops are the data-server =
housekeeping</div><div>and data-server I/O operations. A Layout Type =
like Flex Files can</div><div>report on the housekeeping ones. For the =
Block or Object Layout Types,</div><div>those ops would not make =
sense.</div><div><br></div><div>So everything else comes back to COMMIT, =
READ, WRITE, and PUTFH.</div><div><br></div><div>Are there any other ops =
used for block or object layout drivers?</div><div><br></div><div>And =
the spec could define that if the de_opnum is ILLEGAL, =
it</div><div>signifies that it was a driver specific =
operation.</div><div><br></div><div>The other question is whether the =
client is mapping errors to nfsstat4 or</div><div>using something =
like:</div><div><br></div><div><pre style=3D"word-wrap: break-word; =
white-space: pre-wrap;">   /// enum pnfs_osd_errno4 {
   ///     PNFS_OSD_ERR_EIO            =3D 1,
   ///     PNFS_OSD_ERR_NOT_FOUND      =3D 2,
   ///     PNFS_OSD_ERR_NO_SPACE       =3D 3,
   ///     PNFS_OSD_ERR_BAD_CRED       =3D 4,
   ///     PNFS_OSD_ERR_NO_ACCESS      =3D 5,
   ///     PNFS_OSD_ERR_UNREACHABLE    =3D 6,
   ///     PNFS_OSD_ERR_RESOURCE       =3D 7
   /// };
</pre></div><div>I think the client should do the =
mapping.&nbsp;</div></body></html>=

--Apple-Mail=_F47D922A-BF96-4FA7-AB4F-697134D692E0--