Re: [RFC PATCH v2 00/15] NFSd state containerization

[Stanislav Kinsbursky]

22.11.2012 00:44, J. Bruce Fields ÐÐÑÐÑ:
> On Thu, Nov 15, 2012 at 01:34:08PM -0500, Jeff Layton wrote:
> > On Wed, 14 Nov 2012 17:00:36 -0500
> > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote:
> >
> > > On Wed, Nov 14, 2012 at 06:20:59PM +0300, Stanislav Kinsbursky wrote:
> > > > This patch set is my first attempt to containerize NFSv4 state - i.e. make it
> > > > works in networks namespace context.
> > > > I admit, that some of this new code could be partially rewritten during future
> > > > NFSd containerization.
> > > > But the overall idea look more or less correct to me.
> > > > So, the main things here are:
> > > > 1) making nfs4_client network namespace aware.
> > > > 2) Allocating all hashes (except file_hashtbl and reclaim_str_hashtbl) per
> > > > network namespace context on NFSd start (not init) and destroying on NFSd
> > > > state shutdown.
> > > > 3) Allocating of reclaim_str_hashtbl on legacy tracker start and destroying on
> > > > legacy tracker stop.
> > > > 4) Moving of client_lru and close_lru lists to per-net data.
> > > > 5) Making lundromat network namespace aware.
> > >
> > > These look OK and pass my tests.  Jeff, do the revised recovery bits
> > > look OK?
> > >
> > > Have you done any testing?
> > >
> > > It'd be interesting, for example, to know if there are any pynfs that
> > > fail against the server in a non-init network namespace, but pass
> > > normally.
> > >
> > > --b.
> >
> > I looked over the patches and they look sane to me. I move that they go
> > into your -next branch to soak for a bit.
>
> Stanislav, actually, I'm unclear, since you labeled these "RFC": do you
> consider these patches ready?

Yes, I consider them ready.
I added the "RFC" mark, because I'm not completely sure, this this code wont' be
partially rewritten in future.

> --b.


--
Best regards,
Stanislav Kinsbursky
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/