Re: [nfsv4] [PATCH 2/3] Morph LAYOUTRETURN errors into LAYOUTERROR

Christoph Hellwig <hch@lst.de> Sat, 17 May 2014 09:46 UTC

Date: Sat, 17 May 2014 11:46:41 +0200
From: Christoph Hellwig <hch@lst.de>
To: Tom Haynes <thomas.haynes@primarydata.com>
Message-ID: <20140517094641.GA10722@lst.de>
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> <A4002329-DFFB-4520-BD79-A5617E2F68FF@primarydata.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <A4002329-DFFB-4520-BD79-A5617E2F68FF@primarydata.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Archived-At: http://mailarchive.ietf.org/arch/msg/nfsv4/l7tAkShtMHxTAdeuiOeZGojTqcM
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] [PATCH 2/3] Morph LAYOUTRETURN errors into LAYOUTERROR
Precedence: list

On Fri, May 16, 2014 at 10:43:15AM -0500, Tom Haynes wrote:
> 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?

The problem is that I/O is not done using nfs operations in those layout
drivers, but using block or object storage protocols.

I guess the answer is something like:

"If the operation that caused the error was performed using a layout
 specific storage protocol the operation number of the closest ressembling
 NFS operation should be used.

 For the block volume layout type the various READ/WRITE calls in T10 SBC
 should be mapped to READ and WRITE, and SYNCHRONIZE_CACHE or similar
 operations should be mapped to COMMIT.

 For the object layout type <... file in from the OSD people>

 If there is no corresponding NFS operation, de_opnum should be set to
 ILLEGAL.
"

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

Absolutely!  There is no need to introduce another set of errors, and
it's rather sad that RFC5664 went down that route.

[nfsv4] [PATCH 0/3] Introduce LAYOUTERROR and LAY… Thomas Haynes
[nfsv4] [PATCH 1/3] Allow the client to inform th… Thomas Haynes
[nfsv4] [PATCH 3/3] Reorder the ops, minor typos Thomas Haynes
[nfsv4] [PATCH 2/3] Morph LAYOUTRETURN errors int… Thomas Haynes
Re: [nfsv4] [PATCH 1/3] Allow the client to infor… Christoph Hellwig
Re: [nfsv4] [PATCH 2/3] Morph LAYOUTRETURN errors… Christoph Hellwig
Re: [nfsv4] [PATCH 1/3] Allow the client to infor… Tom Haynes
Re: [nfsv4] [PATCH 2/3] Morph LAYOUTRETURN errors… Tom Haynes
Re: [nfsv4] [PATCH 2/3] Morph LAYOUTRETURN errors… Christoph Hellwig
Re: [nfsv4] [PATCH 1/3] Allow the client to infor… Benny Halevy
Re: [nfsv4] [PATCH 2/3] Morph LAYOUTRETURN errors… Benny Halevy