From: Trond Myklebust <trondmy@hammerspace.com>
To: "alkisg@gmail.com" <alkisg@gmail.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: rsize,wsize=1M causes severe lags in 10/100 Mbps
Date: Thu, 19 Sep 2019 16:11:00 +0000 [thread overview]
Message-ID: <3d00928cd3244697442a75b36b75cf47ef872657.camel@hammerspace.com> (raw)
In-Reply-To: <ee758eaf-c02d-f669-bc31-f30e6b17d92a@gmail.com>
On Thu, 2019-09-19 at 18:58 +0300, Alkis Georgopoulos wrote:
> On 9/19/19 6:08 PM, Trond Myklebust wrote:
> > The default client behaviour is just to go with whatever
> > recommended
> > value the server specifies. You can change that value yourself on
> > the
> > knfsd server by editing the pseudo-file in
> > /proc/fs/nfsd/max_block_size.
>
> Thank you, and I guess I can automate this, by running
> `systemctl edit nfs-kernel-server`, and adding:
> [Service]
> ExecStartPre=sh -c 'echo 32768 > /proc/fs/nfsd/max_block_size'
>
> But isn't it a problem that the defaults cause errors in dmesg and
> severe lags in 10/100 Mbps, and even make 1000 Mbps a lot less
> snappy
> than with 32K?
>
No. It is not a problem, because nfs-utils defaults to using TCP
mounts. Fragmentation is only a problem with UDP, and we stopped
defaulting to that almost 2 decades ago.
However it may well be that klibc is still defaulting to using UDP, in
which case it should be fixed. There are major Linux distros out there
today that don't even compile in support for NFS over UDP any more.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com
next prev parent reply other threads:[~2019-09-19 16:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-19 7:29 rsize,wsize=1M causes severe lags in 10/100 Mbps, what sets those defaults? Alkis Georgopoulos
2019-09-19 15:08 ` Trond Myklebust
2019-09-19 15:58 ` rsize,wsize=1M causes severe lags in 10/100 Mbps Alkis Georgopoulos
2019-09-19 16:11 ` Trond Myklebust [this message]
2019-09-19 19:21 ` Alkis Georgopoulos
2019-09-19 19:51 ` Trond Myklebust
2019-09-19 19:57 ` Alkis Georgopoulos
2019-09-19 20:05 ` Trond Myklebust
2019-09-19 20:20 ` Alkis Georgopoulos
2019-09-19 20:40 ` Trond Myklebust
2019-09-19 21:19 ` Daniel Forrest
2019-09-19 21:42 ` Trond Myklebust
2019-09-19 22:16 ` Daniel Forrest
2019-09-20 9:25 ` Alkis Georgopoulos
2019-09-20 9:48 ` Alkis Georgopoulos
2019-09-20 10:04 ` Alkis Georgopoulos
2019-09-21 7:52 ` Alkis Georgopoulos
2019-09-21 7:59 ` Alkis Georgopoulos
2019-09-21 11:02 ` Alkis Georgopoulos
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=3d00928cd3244697442a75b36b75cf47ef872657.camel@hammerspace.com \
--to=trondmy@hammerspace.com \
--cc=alkisg@gmail.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 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).