On Thu, Dec 30, 2010 at 03:10:20AM -0600, Rob Landley wrote: > On 12/30/2010 02:51 AM, Kirill A. Shutemov wrote: > > On Wed, Dec 29, 2010 at 08:13:50PM -0600, Rob Landley wrote: > >> On Wed, Dec 29, 2010 at 7:14 AM, Kirill A. Shutemov<kas@xxxxxxxxxx> wrote: > >>> > >>> Prepare nfs/sunrpc stack to use multiple instances of rpc_pipefs. > >>> Only for client for now. > >> > >> What would a test case for this look like? (Is there some way to tell > >> an nfs mount to use a specific instance of rpc_pipefs or something?) > > > > You can create a new instance of rpc_pipefs using 'newinstance' > > mountoption. > > > > Then you can specify which rpc_pipefs to use with 'rpcmount' mountoption > > of nfs mount. If none specifed, '/var/lib/nfs/rpc_pipefs' uses by default. > > That path is as the process performing the mount sees it? Yep. > > If no rpcmount mountoption, no rpc_pipefs was found at > > '/var/lib/nfs/rpc_pipefs' and we are in init's mount namespace, we use > > init_rpc_pipefs. > > It's the "we are in init's mount namespace" that I was wondering about. > > So if I naievely chroot, nfs mount stops working the way it did before I > chrooted unless I do an extra setup step? No. It will work as before since you are still in init's mount namespace. Creating new mount namespace changes rules. > I'm actually poking at getting nfs mount working in LXC containers with > different network routing (mostly study so far, it took me a couple > weeks just to get lxc to work for me and now I'm trying to wrap my head > around Linux's NFS implementation), so I'm very interested in this... -- Kirill A. Shutemov -- 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
