From: Christoph Hellwig <hch@infradead.org>
To: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: linux-nfs@vger.kernel.org
Subject: [PATCH, RFC] backchannel overflows
Date: Tue, 28 Apr 2015 13:21:57 -0700 [thread overview]
Message-ID: <20150428202157.GA23972@infradead.org> (raw)
Currently the client will just crap out if a CB_NULL comes in at the
same time as a slot controlled CB_COMPOUND that includes a CB_SEQUENCE.
I don't really understand how the spec wants to treat CB_NULL in
relation to the available backchannel slots, but given that it's
not part of the sequences in CB_SEQUENCE it somehow nees to bypass them.
If we make sure to overallocate the rpc-level buffers so that we
have more than the available NFS-level slots we should be safe from
this condition which makes a 4.1 server doing heavy recalls under
load very unhapy by not returning an NFS level reply to its layout
recalls.
I dont really like this patch much, so any idea for a better solution
would be highly welcome!
diff --git a/fs/nfs/callback.h b/fs/nfs/callback.h
index 84326e9..7afb3ef 100644
--- a/fs/nfs/callback.h
+++ b/fs/nfs/callback.h
@@ -205,7 +205,7 @@ extern int nfs4_set_callback_sessionid(struct nfs_client *clp);
* so we limit their concurrency to 1 by setting up the maximum number
* of slots for the backchannel.
*/
-#define NFS41_BC_MIN_CALLBACKS 1
+#define NFS41_BC_MIN_CALLBACKS 2
#define NFS41_BC_MAX_CALLBACKS 1
extern unsigned int nfs_callback_set_tcpport;
next reply other threads:[~2015-04-28 20:21 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-28 20:21 Christoph Hellwig [this message]
2015-04-29 12:08 ` [PATCH, RFC] backchannel overflows Kinglong Mee
2015-04-29 13:46 ` Christoph Hellwig
2015-04-29 14:55 ` Chuck Lever
2015-04-29 14:58 ` Trond Myklebust
2015-04-29 15:14 ` Christoph Hellwig
2015-04-29 15:24 ` Trond Myklebust
2015-04-29 17:34 ` J. Bruce Fields
2015-04-30 6:25 ` Christoph Hellwig
2015-04-30 14:34 ` Chuck Lever
2015-04-30 14:37 ` Christoph Hellwig
[not found] ` <CAHQdGtRgEVXidNNYtYf4c3uS0vc6fbm-SZ5AxrY=awXYynmACw@mail.gmail.com>
2015-04-30 15:02 ` Trond Myklebust
2015-04-30 15:11 ` Chuck Lever
2015-04-30 17:41 ` Chuck Lever
2015-05-01 17:23 ` Christoph Hellwig
2015-05-01 17:28 ` Trond Myklebust
2015-05-01 17:37 ` Christoph Hellwig
2015-05-01 17:47 ` Trond Myklebust
2015-05-01 17:31 ` Chuck Lever
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=20150428202157.GA23972@infradead.org \
--to=hch@infradead.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@primarydata.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.