[pnfs] [PATCH] save client flags for exchange id
William A. (Andy) Adamson
andros at citi.umich.edu
Tue Jun 5 13:08:49 EDT 2007
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 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/15efe9b0/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Set-the-EXCHANGE_ID-EXCHGID4_FLAG_USE_PNFS_MDS-and-E.patch
Type: application/octet-stream
Size: 1881 bytes
Desc: not available
Url : http://linux-nfs.org/pipermail/pnfs/attachments/20070605/15efe9b0/attachment-0001.obj
More information about the pNFS
mailing list