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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
