Re: [gentoo-dev] Re: An example overlayfs sandbox test

[Rich Freeman]

On Sun, Sep 24, 2017 at 4:24 AM, Martin Vaeth <martin@×××××.de> wrote:
> Tim Harder <radhermit@g.o> wrote:
>
> It is the big advantage of overlay that it is implemented in
> kernel and does not involve any time-consuming checks during
> normal file operations.
>

Why would you expect containers to behave any differently?  Either way
the kernel gets a path and has to figure out where the path is
actually stored, and check the inode for access permissions.

Now, I am concerned about the time to create the container, if we're
going to specify individual files, but the same would be true of an
overlay.

If you create a container and just read-only bind mount all the
top-level dirs from the root filesystem into it, and then mount a
read-write bind mount into the package build directory, that is just a
few operations.  I'd expect that to go fast with either a container or
overlay solution.

If you actually want to go to the next step (which our current sandbox
does not) and only bind mount the specific files specified in DEPEND
and their RDEPEND then you're talking about creating thousands of bind
mounts.  I have no idea how that performs.  However, I suspect it
would be at least as slow to populate an overlayfs with just that
specific list of files.

You can't compare the file-level container solution against the
filesystem-level overlay solution when both solutions can be
implemented either way.  If you just replicate the current sandbox
functionality then setup time is tiny and you get visibility into
write violations only.  If you resolve dependencies and map in
individual files then you additionally get visibility into read
violations, at the cost of more time to create the build environment.

I'd be interested in how other distros are solving this problem,
because fundamentally what we're doing isn't really any different.

-- 
Rich