From: "J. Bruce Fields" <bfields@fieldses.org>
To: Trond Myklebust <trond@netapp.com>
Cc: linux-nfs@vger.kernel.org, Andy Adamson <andros@netapp.com>
Subject: [PATCH] nfs4: allow server to change forechannel max_ops
Date: Tue, 25 May 2010 12:42:24 -0400 [thread overview]
Message-ID: <20100525164224.GC4235@fieldses.org> (raw)
From: J. Bruce Fields <bfields@citi.umich.edu>
Section 18.36.3 of rfc 5661 says that "For the fore channel, the server
MAY change the requested value."
Also, there's no reason why the client would have to care if the server
is willing to accept *more* operations per compound than the client
requested.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
fs/nfs/nfs4proc.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
On the other hand, if the server *decreases* max_ops on the forechannel,
the client may need to do something. (Probably just fail for now.) Why
aren't we checking for that case?
--b.
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 071fced..a5a3690 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -4880,7 +4880,6 @@ static int nfs4_verify_channel_attrs(struct nfs41_create_session_args *args,
ret |= _verify_fore_channel_attr(headerpadsz);
ret |= _verify_fore_channel_attr(max_resp_sz);
- ret |= _verify_fore_channel_attr(max_ops);
ret |= _verify_back_channel_attr(headerpadsz);
ret |= _verify_back_channel_attr(max_rqst_sz);
--
1.7.0.4
next reply other threads:[~2010-05-25 16:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-25 16:42 J. Bruce Fields [this message]
2010-05-25 16:57 ` [PATCH] nfs4: allow server to change forechannel max_ops Trond Myklebust
[not found] ` <1274806624.11283.10.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2010-05-25 18:32 ` J. Bruce Fields
2010-09-07 22:32 ` J. Bruce Fields
2010-10-02 5:19 ` [PATCH] nfs4: fix channel attribute sanity-checks J. Bruce Fields
2010-10-02 9:04 ` Jim Rees
2010-10-02 19:19 ` [PATCH v2] " J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100525164224.GC4235@fieldses.org \
--to=bfields@fieldses.org \
--cc=andros@netapp.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond@netapp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).