Return-Path: Received: from daytona.panasas.com ([67.152.220.89]:18834 "EHLO daytona.int.panasas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754079Ab0IOPbd (ORCPT ); Wed, 15 Sep 2010 11:31:33 -0400 Message-ID: <4C90E6D2.3030008@panasas.com> Date: Wed, 15 Sep 2010 17:31:30 +0200 From: Boaz Harrosh To: Pavel Emelyanov CC: "J. Bruce Fields" , Neil Brown , Trond Myklebust , linux-nfs@vger.kernel.org Subject: Re: [PATCH 0/9] sunrpc: Start making sunrpc work in containers References: <4C90BADB.10700@parallels.com> In-Reply-To: <4C90BADB.10700@parallels.com> Content-Type: text/plain; charset=UTF-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: MIME-Version: 1.0 On 09/15/2010 02:23 PM, Pavel Emelyanov wrote: > Hello everyone! > > I would like to prepare the sunrpc layer for working in a containerized > environments. The ultimate goal is to make both nfs client and server > work in containers. Hopefully you won't object :) > > Not to look like an idle talker I've prepared this set which makes the > /proc/net/rpc appear in net namespaces and made the ip_map_cache be per-net. > > I do not have any plans about when this patches appear at Linus tree and > thus do not know which git tree to hack on. That said I prepared the patches > against the net-next tree (I have some custom netns debugging code in it > and don't want to port it around in vain). > > Looking forward to your feedback. > We are very curios people and would like to know more. What does it mean to work in containers? Why is it better for the client why is it better for the server? who and how to enjoy this benefits. Does it have any effects on the operation of nfs/nfsd? What problem does it solve? Thanks Boaz > Thanks, > Pavel