LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Kirill Tkhai <firstname.lastname@example.org>
To: Steven Rostedt <email@example.com>,
"Eric W. Biederman" <firstname.lastname@example.org>
Cc: "Yordan Karadzhov (VMware)" <email@example.com>,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
email@example.com, Linux Containers <firstname.lastname@example.org>
Subject: Re: [RFC PATCH 0/4] namespacefs: Proof-of-Concept
Date: Fri, 19 Nov 2021 12:50:20 +0300 [thread overview]
Message-ID: <email@example.com> (raw)
On 18.11.2021 22:24, Steven Rostedt wrote:
> On Thu, 18 Nov 2021 12:55:07 -0600
> firstname.lastname@example.org (Eric W. Biederman) wrote:
>> It is not correct to use inode numbers as the actual names for
>> I can not see anything else you can possibly uses as names for
> This is why we used inode numbers.
The migration problem may be solved in case of the new filesystem
Kernel may use random UUID as initial namespace file. After the migration,
we recreate this namespace, and it will have another UUID generated by kernel.
Then, we just rename it in correct one.
I sent something like this for /proc fs (except rename):
>> To allow container migration between machines and similar things
>> the you wind up needing a namespace for your names of namespaces.
> Is this why you say inode numbers are incorrect?
> There's no reason to make this into its own namespace. Ideally, this file
> system should only be for privilege containers. As the entire point of this
> file system is to monitor the other containers on the system. In other
> words, this file system is not to be used like procfs, but instead a global
> information of the containers running on the host.
> At first, we were not going to let this file system be part of any
> namespace but the host itself, but because we want to wrap up tooling into
> a container that we can install on other machines as a way to monitor the
> containers on each machine, we had to open that up.
>> Further you talk about hierarchy and you have not added support for the
>> user namespace. Without the user namespace there is not hierarchy with
>> any namespace but the pid namespace. There is definitely no meaningful
>> hierarchy without the user namespace.
> Great, help us implement this.
>> As far as I can tell merging this will break CRIU and container
>> migration in general (as the namespace of namespaces problem is not
> This is not to be a file system that is to be migrated. As the point of
> this file system is to monitor the other containers, so it does not make
> sense to migrate it.
>> Since you are not solving the problem of a namespace for namespaces,
>> yet implementing something that requires it.
> Why is it needed?
>> Since you are implementing hierarchy and ignoring the user namespace
>> which gives structure and hierarchy to the namespaces.
> We are not ignoring it, we are RFC'ing for advice on how to implement it.
>> Since this breaks existing use cases without giving a solution.
> You don't understand proof-of-concepts and RFCs do you?
> -- Steve
next prev parent reply other threads:[~2021-11-19 9:50 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-18 18:12 Yordan Karadzhov (VMware)
2021-11-18 18:12 ` [RFC PATCH 1/4] namespacefs: Introduce 'namespacefs' Yordan Karadzhov (VMware)
2021-11-18 18:12 ` [RFC PATCH 2/4] namespacefs: Add methods to create/remove PID namespace directories Yordan Karadzhov (VMware)
2021-11-18 18:12 ` [RFC PATCH 3/4] namespacefs: Couple namespacefs to the PID namespace Yordan Karadzhov (VMware)
2021-11-18 18:12 ` [RFC PATCH 4/4] namespacefs: Couple namespacefs to the UTS namespace Yordan Karadzhov (VMware)
2021-11-18 18:55 ` [RFC PATCH 0/4] namespacefs: Proof-of-Concept Eric W. Biederman
2021-11-18 19:02 ` Steven Rostedt
2021-11-18 19:22 ` Eric W. Biederman
2021-11-18 19:36 ` Steven Rostedt
2021-11-18 19:24 ` Steven Rostedt
2021-11-19 9:50 ` Kirill Tkhai [this message]
2021-11-19 12:45 ` James Bottomley
[not found] ` <email@example.com>
2021-11-19 16:42 ` James Bottomley
2021-11-19 17:14 ` Yordan Karadzhov
2021-11-19 17:22 ` Steven Rostedt
2021-11-19 23:22 ` James Bottomley
2021-11-20 0:07 ` Steven Rostedt
2021-11-20 0:14 ` James Bottomley
[not found] ` <f6ca1f5bdb3b516688f291d9685a6a59f49f1393.camel@HansenPartnership.com>
2021-11-19 16:47 ` Steven Rostedt
2021-11-19 16:49 ` Steven Rostedt
2021-11-19 23:08 ` James Bottomley
2021-11-22 13:02 ` Yordan Karadzhov
2021-11-22 13:44 ` James Bottomley
2021-11-22 15:00 ` Yordan Karadzhov
2021-11-22 15:47 ` James Bottomley
2021-11-22 16:15 ` Yordan Karadzhov
2021-11-19 14:26 ` Yordan Karadzhov
2021-11-18 21:24 ` Mike Rapoport
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [RFC PATCH 0/4] namespacefs: Proof-of-Concept' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).