[pnfs] create session on data server

[William A. (Andy) Adamson]

ok. can we push clientid's to the data servers when the MDS completes a
successful CREATE_SESSION?  an issue here is that the MDS doesn't know if
the client will be using pNFS.

-->Andy

On 1/30/07, Marc Eshel <eshel at almaden.ibm.com> wrote:
>
> I am not sure how to do it without a file handle. The file handle tells us
> that this id a pNFS request and also provides us with the MDS id so we
> know who to ask for the state.
>
>
>
>
> "William A. (Andy) Adamson" <andros at citi.umich.edu>
> Sent by: androsadamson at gmail.com
> 01/30/2007 09:30 AM
>
> To
> "Marc Eshel" <eshel at almaden.ibm.com>
> cc
> pnfs at linux-nfs.org
> Subject
> create session on data server
>
>
>
>
>
>
> The non-sessions server code uses the file handle to determine if an
> incoming request is a pNFS request, and therefore this server is acting as
> a data server. Now, in the sessions version the data-server needs to
> respond to a CREATE_SESSION with no preceeding EXCHANGE_ID, and no
> filehandle.
>
> Can we use the existing get_state() interface? When the data server gets a
> clientid it doesn't know about, it calls get_state() with just the
> pnfs_get_state.clid field stuffed. How does the cluster fs know which node
> is the MDS? Is there some info in the clientid?  If the cluster fs can
> determine the MDS, then the MDS can check that the clientid is confirmed,
> and return the pnfs_get_state.clid with the clientid, and the
> pnfs_get_state.devid with the MDS devid.
>
> This is similar to how the data server gets stateids.
>
>
> /* pNFS Metadata to Data server state communication*/
> struct pnfs_get_state {
>         u32                     devid;    /* request */
>         stateid_t               stid;     /* request;response */
>         clientid_t              clid;     /* response */
>         u32                     access;    /* response */
>         u32                     stid_gen;    /* response */
>         u32                     verifier[2]; /* response */
> };
>
> -->Andy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux-nfs.org/pipermail/pnfs/attachments/20070130/5278aa20/attachment.htm