From: Ben Greear <greearb@candelatech.com>
To: Gregory Boyce <gregory.boyce@gmail.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: Problems mounting via UDP from a netapp with multiple interfaces
Date: Thu, 09 Apr 2015 14:08:38 -0700 [thread overview]
Message-ID: <5526EA56.4080606@candelatech.com> (raw)
In-Reply-To: <CALs61ueTJ4_WT00Sqz5TKzhkbrS32UjcQ0zVw6B8ikahE4Rhcw@mail.gmail.com>
On 04/09/2015 12:34 PM, Gregory Boyce wrote:
> Folks,
>
> I've been encountering a problem with NFS clients attempting to mount
> from a netapp via UDP where the netapp is responding on the wrong
> interface. On some of our older systems, this mount worked properly,
> while on newer systems nfs-utils ends up failing the mount. Mounting
> via TCP works fine.
>
> It appears that there has been various related discussions over the
> years, and a relevant Redhat bug opened back in 2006:
>
> http://article.gmane.org/gmane.linux.nfs/22778/match=connect+udp
> https://bugzilla.redhat.com/show_bug.cgi?id=208244
>
> Is there a general recommendation for people in this sort of
> situation? I'm assuming the code is currently using connected UDP
> sockets (I'm more of a sysadmin than a developer). Is there an option
> I'm missing to disable this? Otherwise does anyone know of a patch to
> change the behavior?
I have some patches that allow binding an NFS client to a particular
local IP. You need modified mount.nfs tools as well. These patches
might fix your problem, but I am not certain about that.
My kernel trees have various other patches as well...you can pick out just
the NFS stuff if you care to. Otherwise, the kernel should generally build,
install, and work the same as upstream kernels.
https://github.com/greearb/nfs-utils-ct
# This one has cleaner patch set, but not much testing.
http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.19.dev.y/.git;a=summary
# This is lots of extraneous wifi patches, but has had good testing,
# including the nfs bind-to-local-IP feature.
http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.17.dev.y/.git;a=summary
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2015-04-09 21:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-09 19:34 Problems mounting via UDP from a netapp with multiple interfaces Gregory Boyce
2015-04-09 21:08 ` Ben Greear [this message]
2015-04-10 18:22 ` Gregory Boyce
2015-04-10 18:45 ` Ben Greear
2015-04-10 0:23 ` Trond Myklebust
[not found] ` <CALs61uewbb28BcZ=d_qaYWtvUt5-xLGkn1uMXWhpjb_38f8ZtQ@mail.gmail.com>
2015-04-10 18:45 ` Trond Myklebust
2015-04-10 19:04 ` Gregory Boyce
[not found] ` <CALs61ue2HBxv6bJrGFoDj43vaYc_Jxf4-RJJ-vRBy9j2wn+tXA@mail.gmail.com>
2015-04-14 19:39 ` Gregory Boyce
2015-04-17 17:56 ` Steve Dickson
2015-04-10 3:09 ` Malahal Naineni
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=5526EA56.4080606@candelatech.com \
--to=greearb@candelatech.com \
--cc=gregory.boyce@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 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.