[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    [gentoo-dev] Re: An example overlayfs sandbox test
From:       Martin Vaeth <martin () mvath ! de>
Date:       2017-09-27 16:51:04
Message-ID: slrnosnlo0.mt1.martin () lounge ! imp ! fu-berlin ! de
[Download RAW message or body]

Rich Freeman <rich0@gentoo.org> wrote:
>>
>>          | "simple"       | "fine grained"
>> ---------+----------------+-------------------
>>  Overlay | 1 mount        | 1 mount
>> ---------+----------------+-------------------
>> Container| 10? bind mounts| 1000? bind mounts
>
> Except it is more like:
>
>          | "simple"       | "fine grained"
> ---------+----------------+-------------------
>  Overlay | 1 mount        | 1 mount + 1000? file deletions in the overlay
> ---------+----------------+-------------------
> Container| 1-2 bind mounts| 1000? bind mounts

I was not talking about the time to setup the overlay.
File deletions involve only the latter.

> I left out dev+sys+proc in both cases

No, they were not forgotten:
They are not necessary for the overlay approach!
As I emphasized, you do not even need a single bind for that approach.

> And there is really no difference in performance between 1 mount and
> 10 in practice.

Really? Tested with a few million file creations/deletions/openings etc?
Such a number is not unusual for some projects: Already gentoo-sources
has ~60k files, all of them being accessed several times in various
manner. So even a very small delay multiplies by a huge number.

That's also a reason why I mentioned that a slow machine would be good
for timing. For instance, gentoo-sources needs several minutes to emerge
on a machine with a slow processor and little ram: the harddisk speed
is not the reason for the delay. I would not like to see another
factor due to a sandbox which is perhaps negligible on a fast system.


[prev in list] [next in list] [prev in thread] [next in thread]