Re: [RFC] NFSd laundromat containerization

["bfields@fieldses.org" <bfields@fieldses.org>]

On Sat, May 12, 2012 at 12:59:05PM +0400, Stanislav Kinsbursky wrote:
> On 11.05.2012 17:53, 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.
> >
> 
> Guys, I would like to discuss few ideas about caches and lists containerization.
> Currently, it look to me, that these hash tables:
> 
> reclaim_str, conf_id, conf_str, unconf_str, unconf_id, sessionid
> 
> and these lists:
> 
> client_lru, close_lru
> 
> have to be per net, while hash tables
> 
> file, ownerstr, lockowner_ino
> 
> and
> 
> del_recall_lru lists
> 
> have not, because they are about file system access.

Actually, ownerstr and lockowner_ino should also both be per-container.

So it's only file and del_recall_lru that should be global.  (And
del_recall_lru might work either way, actually.)

> If I'd containerize it this way, then looks like nfs4_lock_state()
> and nfs4_unlock_state() functions will protect only
> non-containerized data, while containerized data have to protected
> by some per-net lock.

Sounds about right.

--b.

> 
> How this approach looks to you?
> 
> 
> -- 
> Best regards,
> Stanislav Kinsbursky