linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: Comments on the bind-to-local IP patch series I posted?
Date: Thu, 24 Jan 2013 11:26:17 -0800	[thread overview]
Message-ID: <51018AD9.2040608@candelatech.com> (raw)
In-Reply-To: <4FA345DA4F4AE44899BD2B03EEEC2FA91833788D@sacexcmbx05-prd.hq.netapp.com>

On 01/24/2013 11:12 AM, Myklebust, Trond wrote:
> On Thu, 2013-01-24 at 10:45 -0800, Ben Greear wrote:
>> I'd really like to get some feedback on whether the patches I posted
>> have a chance at upstream inclusion.  If the whole idea is DOA,
>> then just let me know and I promise not to ask again for a few
>> years :)
>>
>> Otherwise, if any improvements are needed, I'll be happy to work on
>> them.
>
> My stated goal has always been to support this kind of setup through net
> namespaces and containers. Now that Stanislav has added that support (at
> least for the RPC+NFS clients), why do we need a second solution?
>
> IOW: Is there any reason why you can't just use 'virt-sandbox', for
> instance, to start up an lxc session with its own network ip address and
> then run your application?

My application would not work well with that..if for no other reason than it
would be terribly complicated to manage 3000 sandboxes and whatever applications
were running in those sandboxes.

In addition, on multi-homed machines, there can be some general advantages
to allowing binding to specific IP addresses.  A somewhat contrived example
would be two network interfaces on same subnet, wired to a 1G/10G switch.
With binding, you could mount the same server two different times, and spread
the load on the two 1G (client side) interfaces.

Or, just keep all nfs traffic on a particular interface for some other
reason like some small level of security.

 From what I can tell, my patches should not add any real overhead,
and the code is not that complex.

But, I suspect that my handling of the callback binding address could be
problematic if someone wanted to do some strange asymmetric routing,
so I'd probably need a way to make that configurable and disabled
by default.  If the rest of the series has a chance, I'd like to
ask your opinion on a preferred way to configure this.


Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


      reply	other threads:[~2013-01-24 19:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-24 18:45 Comments on the bind-to-local IP patch series I posted? Ben Greear
2013-01-24 19:12 ` Myklebust, Trond
2013-01-24 19:26   ` Ben Greear [this message]

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=51018AD9.2040608@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=Trond.Myklebust@netapp.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).