From: Bennett Amodio <bamodio@purestorage.com>
To: linux-nfs@vger.kernel.org
Cc: anna.schumaker@netapp.com, trond.myklebust@primarydata.com,
Igor Ostrovsky <igor@purestorage.com>,
Vas Chellappa <vas@purestorage.com>,
Jui-Yu Chang <juchang@purestorage.com>
Subject: [RFC v3 0/2] NFSv3 and NFSv4 Multipathing
Date: Tue, 15 Aug 2017 17:46:07 -0700 [thread overview]
Message-ID: <CAKk7tABTTRNxZDD3SXmNpw55CqHaR=gGV6H-eRK5-m0vmkOLWQ@mail.gmail.com> (raw)
After seeing Trond=E2=80=99s patches for NFS multipathing on NFSv4.1, we
decided to try using the same concept for NFSv3/4. The primary issue
we identified was XID collision in the duplicate request cache (replay
cache) for NFSv3/4. In NFSv3/4, entries are hashed based on XID
instead of the slot ID and sequence ID that NFSv4.1 uses. Since the
XIDs are generated by the RPC transports, and Trond=E2=80=99s patches creat=
e
multiple transports for multipathing, different transports can end up
using an overlapping set of XIDs.
To fix this, we apply a mask to XIDs. Each transport is constrained to
its own segment of the total XID range, and they can never overlap.
In terms of loss of entropy, by masking out just enough bits from the
XID, we are convinced that the probability of XID wraparound or
collision on NFS client restart has not increased to a problematic
level (so long as the RPCs are distributed round-robin, as in Trond=E2=80=
=99s
patches).
We tested multipathing out and discovered that it enables NFS to get
more bandwidth on a bonded interface (instead of using only one
physical link, it can use multiple). Specifically, we tested on a
setup where the client was connected to the server via 4 bonded 10Gb/s
links. Without multipathing, the client could only achieve 10Gb/s
(using one physical link). With multipathing, the client was able to
achieve a maximum of close to 40Gb/s.
However, although the maximum performance was close to 40Gb/s,
achieving an average throughput of even 30Gb/s required many
connections. The performance of individual trials had a high
variance. We traced this uneven performance to colliding network
paths. With round-robin distribution of RPCs, no single TCP
connection can exceed the performance of the slowest one. If the
connections are distributed unevenly across network paths, some
connections can bottleneck others. To solve this problem, we are
currently working on patches to provide load-balancing as an
alternative to round-robin for distributing RPCs.
To use these patches, you first have to apply Trond's 5 patches
(Available at https://www.spinics.net/lists/linux-nfs/msg63368.html).
Let us know what you think or if you have any ideas for improving
this.
Jui-Yu Chang (1):
NFS: Allow multiple connections to NFSv3 and NFSv4.0 servers
Bennett Amodio (1):
SUNRPC: Mask XIDs to prevent replay cache collision
fs/nfs/client.c | 3 +++
fs/nfs/nfs4client.c | 2 +-
include/linux/sunrpc/xprt.h | 5 +++++
net/sunrpc/clnt.c | 8 ++++++++
net/sunrpc/xprt.c | 14 ++++++--------
5 files changed, 23 insertions(+), 9 deletions(-)
--
1.9.1
next reply other threads:[~2017-08-16 0:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-16 0:46 Bennett Amodio [this message]
2017-08-18 14:57 ` [RFC v3 0/2] NFSv3 and NFSv4 Multipathing Trond Myklebust
2017-08-18 20:15 ` Bennett Amodio
2017-08-18 23:31 ` Trond Myklebust
2017-08-23 23:43 ` Bennett Amodio
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='CAKk7tABTTRNxZDD3SXmNpw55CqHaR=gGV6H-eRK5-m0vmkOLWQ@mail.gmail.com' \
--to=bamodio@purestorage.com \
--cc=anna.schumaker@netapp.com \
--cc=igor@purestorage.com \
--cc=juchang@purestorage.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@primarydata.com \
--cc=vas@purestorage.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).