[pnfs] [PATCH] save client flags for exchange id

[Marc Eshel]

Hi Andy.
I think that we need to talk about it some more maybe in out status 
meeting. For now we need a working server and I see nothing wrong with 
taking the client indication (flag) that it is trying to exchange id with 
an MDS or DS. Can you please push "fix recall layout for fsid" patch.
Thanks, Marc.

androsadamson at gmail.com wrote on 06/05/2007 08:55:08 AM:

> Hi Marc
> 
> For the 4.1-sessions branch, nfsd4_set_ex_flags() returns the 
> correct flags - we don't care what the client sends, and should not 
> save the eia_flags.
> 
> For the master branch, here is what I think we need to do. 
> 
> As in the 4.1-sessions case, Return support for referrals, no 
> support for migration.
> EXCHGID4_FLAG_SUPP_MOVED_REFER   yes
> EXCHGID4_FLAG_SUPP_MOVED_MIGR    no
> 
> As for the pNFS flags: 
> 
> Just like the 4.1-sessions branch, we always set this, because we 
> support sessions w/o pNFS.
> EXCHGID4_FLAG_USE_NON_PNFS     yes
> Now we have the chicken-or-egg problem. We currently can only tell 
> if we support pNFS via the export operations functions such as 
> export_ops->layout_type(). But the server doesn't know about any of 
> it's exports until the first filehandle show up, and an upcall is 
> made to get the export struct, and the first filehandle for an 
> export won't appear until after the session is setup. 
> 
> If the server is acting as an MDS, we can't tell at EXCHANGE_ID time.
> If the server is acting only as a DS, we can't tell at EXCHANGE_ID time.
> If the server is acting as an MDS and as a DS, we currently can't 
> tell the difference between a 2nd MDS session or the first DS 
> session at EXCHANGE_ID time. 
> 
> We may need to push configuration information down to the NFSv4.1 
> pNFS MDS/DS server, probably via adding to the existing proc 
> interface; or possibly query the file system with a new export_op 
> when we get the first filehandle (PUTROOTFH), because draft-ietf-
> nfsv4-minorversion1-10 has the following MUST (line 23843): 

>  23825      The response to the SEQUENCE operation contains a word of 
status
>  23826      flags (sr_status_flags) that that can provide to the client
>  23827      information related to the status of the client's lock state 
and
> 
>  23828      communications paths.  Note that any status bits relating to 
lock
>  23829      state are MAY reset when lock state is lost due to a 
> server reboot or
>  23830      the establishment of a new client instance.  Note that 
> if the client
> 
>  23831      ID implied by sa_sessionid was established with
>  23832 
>  23833      (
>  23834       eir_flags
>  23835       & (
>  23836            EXCHGID4_FLAG_USE_PNFS_DS
>  23837          | EXCHGID4_FLAG_USE_PNFS_MDS
> 
>  23838          | EXCHGID4_FLAG_USE_NON_PNFS
>  23839         )
>  23840      ) ==  EXCHGID4_FLAG_USE_PNFS_DS)
>  23841 
>  23842      in the EXCHANGE_ID results (i.e the client ID is only for 
data
>  23843      servers), then sr_status_flags MUST always be zero.

> 
> Until then, the master branch should simply set these flags as follows:

> EXCHGID4_FLAG_USE_PNFS_MDS   yes
> EXCHGID4_FLAG_USE_PNFS_DS    yes
> I don't see any reason to pay attention to what the client sends. 
> In any event, I want to do this inside nfsd4_set_ex_flags(), not 
> copy the input flags prior to the call.
> 
> If we are in agreement, I'll provide the patch...
> 
> -->Andy

> On 6/4/07, Marc Eshel <eshel at almaden.ibm.com> wrote:
> From: Marc Eshel <eshel at almaden.ibm.com>
> 
> 
> ---
> 
> fs/nfsd/nfs4state.c |    1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c 
> index a5e4dc7..2fe5414 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -1202,6 +1202,7 @@ out_copy:
>          clid->clientid.cl_id = new->cl_clientid.cl_id;
> 
>          new->cl_seqid = clid->seqid = 1; 
> +       new->cl_exchange_flags = clid->flags;
>         nfsd4_set_ex_flags(new, clid);
> 
>         dprintk("nfsd4_exchange_id seqid %d flags %x\n",
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux-nfs.org/pipermail/pnfs/attachments/20070605/3138bd67/attachment.htm