[pnfs] [PATCH] save client flags for exchange id
Marc Eshel
eshel at almaden.ibm.com
Tue Jun 5 13:35:52 EDT 2007
Sure, that looks like it should also work.
Marc.
androsadamson at gmail.com wrote on 06/05/2007 10:08:49 AM:
>
> On 6/5/07, Marc Eshel <eshel at almaden.ibm.com> wrote:
>
> 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.
>
>
> ok.
>
> Can you please push "fix recall layout for fsid" patch.
>
>
> how about this patch? (also attached). it sets the input MDS and/or
> DS flags, or both if non are set.
>
>
> -->Andy
>
> fs/nfsd/nfs4state.c | 8 ++++++++
> include/linux/nfs4.h | 1 +
> 2 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index a5e4dc7..bb24562 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -1106,6 +1106,7 @@ void nfsd4_setup_callback_channel(void)
> void
> nfsd4_set_ex_flags(struct nfs4_client *new, struct nfsd4_exchange_id
*clid)
> {
> + int mds_ds = 0;
> /* if sessions only, ignore the wire_flags from client */
>
> /* Referrals are supported, Migration is not. */
> @@ -1114,6 +1115,13 @@ nfsd4_set_ex_flags(struct nfs4_client *new,
> struct nfsd4_exchange_id *clid)
> /* pNFS is not supported */
> new->cl_exchange_flags |= EXCHGID4_FLAG_USE_NON_PNFS;
>
> + /* Save the client's MDS or DS flags, or set both */
> + mds_ds = clid->flags & EXCHGID4_MFS_DS_FLAG_MASK;
> + if (mds_ds)
> + new->cl_exchange_flags |= mds_ds;
> + else
> + new->cl_exchange_flags |= EXCHGID4_MFS_DS_FLAG_MASK;
> +
> /* set the wire flags to return to client. */
> clid->flags = new->cl_exchange_flags;
> }
> diff --git a/include/linux/nfs4.h b/include/linux/nfs4.h
> index 8fad35e..c1748c6 100644
> --- a/include/linux/nfs4.h
> +++ b/include/linux/nfs4.h
> @@ -98,6 +98,7 @@
> #define EXCHGID4_FLAG_USE_NON_PNFS 0x00010000
> #define EXCHGID4_FLAG_USE_PNFS_MDS 0x00020000
> #define EXCHGID4_FLAG_USE_PNFS_DS 0x00040000
> +#define EXCHGID4_MFS_DS_FLAG_MASK 0x00060000
> #define EXCHGID4_INVAL_FLAG_MASK 0x77707774
>
> #define NFS4_LENGTH_EOF (~(u64)0)
>
>
>
>
> 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 wordof
status
> > 23826 flags (sr_status_flags) that that can provide to the
client
> > 23827 information related to the status of the client's
lockstate 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",
> [attachment "0001-Set-the-EXCHANGE_ID-EXCHGID4_FLAG_USE_PNFS_MDS-
> and-E.patch" deleted by Marc Eshel/Almaden/IBM]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux-nfs.org/pipermail/pnfs/attachments/20070605/ff206c37/attachment.htm
More information about the pNFS
mailing list