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

[William A. (Andy) Adamson]

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/e9fbcb28/attachment.htm