[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m11r9umb4y.fsf@fess.ebiederm.org>
Date: Tue, 25 May 2021 22:23:09 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Menglong Dong <menglong8.dong@...il.com>
Cc: Luis Chamberlain <mcgrof@...nel.org>,
Josh Triplett <josh@...htriplett.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Kees Cook <keescook@...omium.org>,
Sami Tolvanen <samitolvanen@...gle.com>, ojeda@...nel.org,
johan@...nel.org, Bjorn Helgaas <bhelgaas@...gle.com>,
masahiroy@...nel.org, Menglong Dong <dong.menglong@....com.cn>,
joe@...ches.com, Jens Axboe <axboe@...nel.dk>, hare@...e.de,
Jan Kara <jack@...e.cz>, tj@...nel.org,
gregkh@...uxfoundation.org, song@...nel.org,
NeilBrown <neilb@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
f.fainelli@...il.com, arnd@...db.de,
Rasmus Villemoes <linux@...musvillemoes.dk>,
wangkefeng.wang@...wei.com, Barret Rhoden <brho@...gle.com>,
mhiramat@...nel.org, Steven Rostedt <rostedt@...dmis.org>,
vbabka@...e.cz, Alexander Potapenko <glider@...gle.com>,
pmladek@...e.com, Chris Down <chris@...isdown.name>,
jojing64@...il.com, terrelln@...com, geert@...ux-m68k.org,
mingo@...nel.org, linux-fsdevel@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>, jeyu@...nel.org
Subject: Re: [PATCH v2 2/3] init/do_cmounts.c: introduce 'user_root' for initramfs
Menglong Dong <menglong8.dong@...il.com> writes:
> On Wed, May 26, 2021 at 2:50 AM Eric W. Biederman <ebiederm@...ssion.com> wrote:
>>
> ......
>>
>> What is the flow where docker uses an initramfs?
>>
>> Just thinking about this I am not being able to connect the dots.
>>
>> The way I imagine the world is that an initramfs will be used either
>> when a linux system boots for the first time, or an initramfs would
>> come from the distribution you are running inside a container. In
>> neither case do I see docker being in a position to add functionality
>> to the initramfs as docker is not responsible for it.
>>
>> Is docker doing something creating like running a container in a VM,
>> and running some directly out of the initramfs, and wanting that code
>> to exactly match the non-VM case?
>>
>> If that is the case I think the easy solution would be to actually use
>> an actual ramdisk where pivot_root works.
>
> In fact, nowadays, initramfs is widely used by embedded devices in the
> production environment, which makes the whole system run in ram.
>
> That make sense. First, running in ram will speed up the system. The size
> of the system won't be too large for embedded devices, which makes this
> idea work. Second, this will reduce the I/O of disk devices, which can
> extend the life of the disk. Third, RAM is getting cheaper.
>
> So in this scene, Docker runs directly in initramfs.
That is the piece of the puzzle I was missing. An small system
with it's root in an initramfs.
>> I really don't see why it makes sense for docker to be a special
>> snowflake and require kernel features that no other distribution does.
>>
>> It might make sense to create a completely empty filesystem underneath
>> an initramfs, and use that new rootfs as the unchanging root of the
>> mount tree, if it can be done with a trivial amount of code, and
>> generally make everything cleaner.
>>
>> As this change sits it looks like a lot of code to handle a problem
>> in the implementation of docker. Which quite frankly will be a pain
>> to have to maintain if this is not a clean general feature that
>> other people can also use.
>>
>
> I don't think that it's all for docker, pivot_root may be used by other
> users in the above scene. It may work to create an empty filesystem, as you
> mentioned above. But I don't think it's a good idea to make all users,
> who want to use pivot_root, do that. After all, it's not friendly to
> users.
>
> As for the code, it may look a lot, but it's not complex. Maybe a clean
> up for the code I add can make it better?
If we are going to do this something that is so small and clean it can
be done unconditionally always.
I will see if I can dig in and look at little more. I think there is
a reason Al Viro and H. Peter Anvin implemeted initramfs this way.
Perhaps it was just a desire to make pivot_root unnecessary.
Container filesystem setup does throw a bit of a wrench in the works as
unlike a initramfs where you can just delete everything there is not
a clean way to get rid of a root filesystem you don't need without
pivot_root.
The net request as I understand it: Make the filesystem the initramfs
lives in be an ordinary filesystem so it can just be used as the systems
primary filesystem.
There might be technical reasons why that is a bad idea and userspace
would be requested to move everything into another ramfs manually (which
would have the same effect). But it is take a good look to see if it
can be accomplished cleanly.
Eric
Powered by blists - more mailing lists