From: "J. Bruce Fields" <bfields@fieldses.org>
To: "McAninley, Jason" <jmcaninl@harris.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: Question regard NFS 4.0 buffer sizes
Date: Tue, 11 Feb 2014 11:32:15 -0500 [thread overview]
Message-ID: <20140211163215.GA19599@fieldses.org> (raw)
In-Reply-To: <322949BF788C8D468BEA0A321B79799098BDBB0A@MLBMXUS20.cs.myharris.net>
On Tue, Feb 11, 2014 at 03:01:39PM +0000, McAninley, Jason wrote:
> Thanks for the reply, Bruce.
>
> > Are you using UDP or TCP?
>
> TCP.
>
> > And what do you mean by "maximum packet size"?
>
> I'm generally referring to the Frame size (e.g. 32,626) and/or the TCP packet size (e.g. 32560) - The former being the size of the latter plus the ethernet/IP headers.
>
> > To see if the maximum rsize/wsize is being used you'd need to look for
> > the length of the data in a READ reply or WRITE call.
>
> Right. When I check the contents of a WRITE RPC, I see "Data" length of 32768 (32k).
>
> My understanding is that setting {r,w}size doesn't guarantee that will be the agreed-upon value. Apparently one must check the value in /proc. I have verified this by checking the value of /proc/XXXX/mounts, where XXXX is the pid for nfsv4.0-svc on the client. It is set to a value >32K.
I don't think that actually takes into account the value returned from
the server. If you watch the mount in wireshark early on you should see
it query the server's rsize and wsize, and you may find that's less.
> > What actual problem are you trying to solve? (Is your read or write
> > bandwidth lower than you expected?)
>
> I am trying to maximize throughout within a parallel processing cluster. We have GigE connections within our closed network and I would like to ensure we are fully utilizing our bandwidth. Additionally, I find a lot of information online (that is not outdated) suggests various Kernel/OS/NFS settings without giving details for why the settings should be modified.
If you haven't already I'd first recommend measuring your NFS read and
write throughput and comparing it to what you can get from the network
and the server's disk. No point tuning something if it turns out it's
already working.
--b.
>
> Upon changing the rsize/wsize, I would have expected to see a change in the packet/payload size, but I do not.
>
> -Jason
next prev parent reply other threads:[~2014-02-11 16:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-11 12:32 Question regard NFS 4.0 buffer sizes McAninley, Jason
2014-02-11 14:36 ` J. Bruce Fields
2014-02-11 15:01 ` McAninley, Jason
2014-02-11 16:32 ` J. Bruce Fields [this message]
2014-02-11 21:17 ` McAninley, Jason
2014-02-11 21:54 ` J. Bruce Fields
2014-02-11 22:50 ` McAninley, Jason
2014-02-11 23:18 ` Malahal Naineni
2014-02-13 12:21 ` McAninley, Jason
2014-02-13 18:21 ` J. Bruce Fields
2014-02-11 17:22 ` 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=20140211163215.GA19599@fieldses.org \
--to=bfields@fieldses.org \
--cc=jmcaninl@harris.com \
--cc=linux-nfs@vger.kernel.org \
/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.