From: Harshula <harshula@redhat.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Jeff Layton <jlayton@redhat.com>, Jim Rees <rees@umich.edu>,
Steve Dickson <SteveD@redhat.com>, NeilBrown <neilb@suse.de>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: "Using NFS over UDP on high-speed links such as Gigabit can cause silent data corruption."
Date: Mon, 05 Mar 2012 13:17:05 +1100 [thread overview]
Message-ID: <1330913825.9157.61.camel@serendib> (raw)
In-Reply-To: <7C4B183F-8357-4D08-B30A-73196954A5D4@oracle.com>
On Tue, 2012-02-28 at 10:50 -0500, Chuck Lever wrote:
> On Feb 28, 2012, at 9:35 AM, Chuck Lever wrote:
> > My comment is that if the text in the TRANSPORT METHODS section in
> nfs(5) about UDP reassembly is not adequate it should be updated. I
> would rather see the meat of the proposed text merged into that
> section; otherwise we have two disparate sections discussing the same
> topic. That section is where this kind of discussion belongs.
Good point. I'll try to massage the text into that section.
> A few more comments.
>
> Any file, including a /proc file, called out in new text should be
> added to the FILES section, IMO.
>
> If we can't resolve the provenance issue, someone could rewrite the
> patch from scratch so that it addresses the review comments.
We now know who authored (Olaf Kirch) and committed (Mads Martin
Joergensen) the text at SUSE. Do we need to get a sign-off from someone
at SUSE?
> I don't agree with adding in-code warnings. Mount works silently
> unless it fails, and this is not a mount failure. Would such warnings
> ever be seen for NFS mounts added to /etc/fstab, or performed by
> automounter? I think by and large most people type "mount -t nfs"
> without options and will get our current default transport setting,
> which is TCP, or UDP if the server does not support TCP. Isn't that
> adequate?
>
> We also know that the risk of using UDP is mitigated by using jumbo
> frames, specifying a small r/wsize, or by reducing the fragment
> reassembly timeout. If an admin does those things, she still gets the
> warning.
>
> It seems needlessly alarmist, and useless for our most common use
> cases.
Sounds reasonable. Just the man page text then.
cya,
#
next prev parent reply other threads:[~2012-03-05 2:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-28 5:22 "Using NFS over UDP on high-speed links such as Gigabit can cause silent data corruption." Harshula
2012-02-28 11:52 ` Jeff Layton
2012-02-28 12:32 ` Harshula
2012-02-28 12:41 ` Jeff Layton
2012-03-05 1:56 ` Harshula
2012-02-28 12:46 ` Jim Rees
2012-02-28 12:57 ` Jeff Layton
2012-02-28 14:35 ` Chuck Lever
2012-02-28 15:09 ` Jim Rees
2012-02-28 15:50 ` Chuck Lever
2012-03-05 2:17 ` Harshula [this message]
2012-03-05 15:08 ` Chuck Lever
2012-05-09 0:59 ` [PATCH] nfs-utils: Add a warning to the nfs manpage regarding using NFS over UDP on high-speed links Harshula Jayasuriya
2012-05-09 18:14 ` Steve Dickson
2012-05-09 18:38 ` Peter Staubach
2012-05-09 22:16 ` Harshula
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=1330913825.9157.61.camel@serendib \
--to=harshula@redhat.com \
--cc=SteveD@redhat.com \
--cc=chuck.lever@oracle.com \
--cc=jlayton@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=rees@umich.edu \
/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).