From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: linux-nfs-owner@vger.kernel.org Received: from relay.parallels.com ([195.214.232.42]:59641 "EHLO relay.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760012Ab2EKOPm (ORCPT ); Fri, 11 May 2012 10:15:42 -0400 Message-ID: <4FAD1F03.8060909@parallels.com> Date: Fri, 11 May 2012 18:15:31 +0400 From: Stanislav Kinsbursky MIME-Version: 1.0 To: Jeff Layton CC: "bfields@fieldses.org" , "linux-nfs@vger.kernel.org" Subject: Re: [RFC] NFSd laundromat containerization References: <4FAD1934.8070908@parallels.com> <20120511135306.GA12795@fieldses.org> <20120511100238.1c3f2bd4@tlielax.poochiereds.net> In-Reply-To: <20120511100238.1c3f2bd4@tlielax.poochiereds.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Sender: linux-nfs-owner@vger.kernel.org List-ID: On 11.05.2012 18:02, Jeff Layton wrote: > On Fri, 11 May 2012 09:53:07 -0400 > "bfields@fieldses.org" wrote: > >> On Fri, May 11, 2012 at 05:50:44PM +0400, Stanislav Kinsbursky wrote: >>> Hello. >>> I'm currently looking on NFSd laundromat work, and it looks like >>> have to be performed per networks namespace context. >>> It's easy to make corresponding delayed work per network namespace >>> and thus gain per-net data pointer in laundromat function. >>> But here a problem appears: network namespace is required to skip >>> clients from other network namespaces while iterating over global >>> lists (client_lru and friends). >>> I see two possible solutions: >>> 1) Make these list per network namespace context. In this case >>> network namespace will not be required - per-net data will be >>> enough. >>> 2) Put network namespace link on per-net data (this one is easier, but uglier). >> >> I'd rather there be as few shared data structures between network >> namespaces as possible--I think that will simplify things. >> >> So, of those two choices, #1. >> > > Agreed, that's sort of how I envisioned things going. In general, > you'll want to move things that were one global structures to struct > nfsd_net, and fix up the code to manage that on a per-ns basis. > Ok. I'll do it in first way. Anyway, this patch set with laundromat will depends on grace period containerization. > The catch here is that the laundromat is somewhat intertwined with the > grace period, and you need to consider how to handle the grace period > between different namespaces. Do we keep a single grace period > per-machine as we have today? Or do we move to a per-ns grace period > that is started whenever someone starts up knfsd within the container? > Second one. You can have a look at "Lockd: grace period containerization" patch set I've sent last week. -- Best regards, Stanislav Kinsbursky