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

[Tom Haynes <[e-mail]>]

On May 16, 2014, at 3:23 AM, Christoph Hellwig <[e-mail]> 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.