--- Glasgow_Jason@emc.com wrote:
> From: Glasgow_Jason@emc.com
> Date: Fri, 11 Jan 2008 14:45:46 -0500
> To: <nfsv4@ietf.org>
> Subject: [nfsv4] Changes to GETDEVICELIST in NFSv41 I-D 15 and 18
>
> The argument list "struct GETDEVICELIST4args" changed in draft 18
> removing
> "/* CURRENT_FH: file */".
>
> This change made it apparent to me that in draft 15, the definition
> of
> GETDEVICELIST was changed to "enumerate all of the device ID to
> device
> address mappings in use by the server". In contrast, in draft 14,
> GETDEVICELIST was defined to return "all the devices associated with
> a
> file system".
>
> I apologize for not noticing this earlier, but the change is
> significant. IMHO, GETDEVICELIST is much more useful if the mappings
> it
> provides relate to a given file system, rather than to all devices
> used
> by the server. The reason is that the former allows a client to
> evaluate if it can access the devices required to do pNFS for a given
> file system, whereas the later provides no such ability. In the
> later
> definition there is no way (short of issuing LAYOUTGET for a file) to
> associate device ids with a given file system. This is particularly
> useful when a user mounts a file system.
>
> I propose that the CURRENT_FH be added back to the definition of
> GETDEVICELIST4args and that the first paragraph description be
> revised
> to read:
>
> This operation is used by the client to enumerate all of the
> device
> ID to device address mappings in use by a file system. An example
> of
> the use of this operation is for device types that use SAN devices
> and in these environments it may be helpful for a client to
> determine
> device accessibility upon first file system access.
>
> If the current file handle is the root file handle, the server
> should
> respond with all devices in use by the server. On success, the
> current
> filehandle retains its value.
>
>
> Among other reasons, I think that the current file handle was removed
> due to confusion generated by the addition in draft 15 and subsequent
> removal in 18 of device stateids.
>
> (See the thread
> http://www1.ietf.org/mail-archive/web/nfsv4/current/msg04899.html
> and
> http://www1.ietf.org/mail-archive/web/nfsv4/current/msg04903.html
> )
>
> Comments?
>
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4
>
|