Subject: [nfsv4] Re: draft-ietf-nfsv4-minorversion1-01.txt pNFS ops redundant layout type in GETDEVICELIST4resok

From: Spencer Shepler <[email-masked]>
Date: Fri, 17 Mar 2006 16:59:38 -0600

I failed to include this into -02 and have created
http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/issue8
to track its inclusion.

Spencer

On Thu, William A.(Andy) Adamson wrote:
> 
> I posted these suggested changes to the list a while back (attached) - some 
> discussion ensued, and it seems like there was consensus to go ahead with the 
> changes. Here are the exact/final proposed changes.
> 
> From
> ----
> 
> 10.4  pnfs_devlist_item4
> 
>      struct pnfs_devlist_item4 {
>             pnfs_deviceid4          id;
>             pnfs_deviceaddr4        addr;
>      };
> 
>    An array of these values is returned by the GETDEVICELIST operation.
>    They define the set of devices associated with a file system.
> 
> To
> ---
> 
> 10.4  pnfs_devlist_item4
> 
>      struct pnfs_devlist_item4 {
>             pnfs_deviceid4          id;
>             opaque                  device_addr<>;
>      };
> 
>    An array of these values is returned by the GETDEVICELIST operation.
>    They define the set of devices associated with a file system for the
>    layout type specified in the GETDEVICELIST4args.
> 
> 
> From
> ----
> 
> 14.18   GETDEVICELIST - Get List of Devices
> 
> 
>    DESCRIPTION 
> 
>    In some applications, especially SAN environments, it is convenient
>    to find out about all the devices associated with a file system.
>    This lets a client determine if it has access to these devices, e.g.,
>    at mount time.
> 
>    This operation returns an array of items (pnfs_devlist_item4) that
>    establish the association between the short pnfs_deviceid4 and the
>    addressing information for that device, for a particular layout type.
>    This operation may not be able to fetch all device information at
>    once, thus it uses a cookie based approach, similar to READDIR, to
>    fetch additional device information (see [2], section 14.2.24).  As
> 
> 
> To
> ---
> 
>   DESCRIPTION 
> 
>    In some applications, especially SAN environments, it is convenient
>    to find out about all the devices associated with a file system.
>    This lets a client determine if it has access to these devices, e.g.,
>    at mount time.
> 
>    This operation returns an array of items (pnfs_devlist_item4) that
>    establish the association between the short pnfs_deviceid4 and the
>    addressing information for that device, for the layout type
>    specified in the GETDEVICELIST4args.
>    This operation may not be able to fetch all device information at
>    once, thus it uses a cookie based approach, similar to READDIR, to
>    fetch additional device information (see [2], section 14.2.24).  As
> 
> 
> 
> -->Andy
> 
> 
> 

Content-Description: 463
> Date: Fri, 13 Jan 2006 11:54:38 -0500
> From: "William A.(Andy) Adamson" <[email-masked]>
> Subject: [nfsv4] draft-ietf-nfsv4-minorversion1-01.txt: pNFS ops: redundant
>  pnfs_layouttype4 in GETDEVICELIST4resok
> To: [email-masked]
> 
> 
> the client specifies the pnfs_layouttype4 it wants devices for in the 
> GETDEVICELIST4args.
> 
>     struct GETDEVICELIST4args {
>              /* CURRENT_FH: file */
>              pnfs_layouttype4                layout_type;
>              count4                          maxcount;
>              nfs_cookie4                     cookie;
>              verifier4                       cookieverf;
>      };
> 
> in the result, there is an opaque pnfs_devlist_item4; the list of devices for 
> the
> layout type specified in the GETDEVICELIST4args.
> 
>    RESULT
> 
>      struct GETDEVICELIST4resok {
>              nfs_cookie4                     cookie;
>              verifier4                       cookieverf;
>              pnfs_devlist_item4              device_addrs<>;
>      };
> 
> 
>     struct pnfs_devlist_item4 {
>             pnfs_deviceid4          id;
>             pnfs_deviceaddr4        addr;
>      };
> 
> but, the pnfs_deviceaddr4 member of pnfs_devlist_item4 also has a 
> pnfs_layouttype4.
> 
> 
>     struct pnfs_deviceaddr4 {
>               pnfs_layouttype4 type;
>               opaque           device_addr<>;
>      };
> 
> as far as i can tell, this is redundant - its value will never be different 
> from the pnfs_layouttype4 requested by the client in GETDEVICELIST4args.
> 
> so, i propose we change the declaration of struct pnfs_devlist_item4 which is 
> only used in GETDEVICELIST4resok as follows:
> 
>  struct pnfs_devlist_item4 {
>             pnfs_deviceid4          id;
>             opaque                  device_addr<>; /* of pnfs_layouttype4 
> specified in GETDEVICELIST4args */
>      };
> 
> removing the redundant pnfs_layouttype4.
> 
> 
> i also propose we change the text of GETDEVICELIST Description from
> 
>   This operation returns an array of items (pnfs_devlist_item4) that
>    establish the association between the short pnfs_deviceid4 and the
>    addressing information for that device, for a particular layout type.
> 
> to 
>   
>    This operation returns an array of items (pnfs_devlist_item4) that
>    establish the association between the short pnfs_deviceid4 and the
>    addressing information for that device, for the layout type
>    specified in GETDEVICELIST4args.
> 
> -->Andy
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4

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