1 |
Rich Freeman <rich0@g.o> wrote: |
2 |
>> |
3 |
>> | "simple" | "fine grained" |
4 |
>> ---------+----------------+------------------- |
5 |
>> Overlay | 1 mount | 1 mount |
6 |
>> ---------+----------------+------------------- |
7 |
>> Container| 10? bind mounts| 1000? bind mounts |
8 |
> |
9 |
> Except it is more like: |
10 |
> |
11 |
> | "simple" | "fine grained" |
12 |
> ---------+----------------+------------------- |
13 |
> Overlay | 1 mount | 1 mount + 1000? file deletions in the overlay |
14 |
> ---------+----------------+------------------- |
15 |
> Container| 1-2 bind mounts| 1000? bind mounts |
16 |
|
17 |
I was not talking about the time to setup the overlay. |
18 |
File deletions involve only the latter. |
19 |
|
20 |
> I left out dev+sys+proc in both cases |
21 |
|
22 |
No, they were not forgotten: |
23 |
They are not necessary for the overlay approach! |
24 |
As I emphasized, you do not even need a single bind for that approach. |
25 |
|
26 |
> And there is really no difference in performance between 1 mount and |
27 |
> 10 in practice. |
28 |
|
29 |
Really? Tested with a few million file creations/deletions/openings etc? |
30 |
Such a number is not unusual for some projects: Already gentoo-sources |
31 |
has ~60k files, all of them being accessed several times in various |
32 |
manner. So even a very small delay multiplies by a huge number. |
33 |
|
34 |
That's also a reason why I mentioned that a slow machine would be good |
35 |
for timing. For instance, gentoo-sources needs several minutes to emerge |
36 |
on a machine with a slow processor and little ram: the harddisk speed |
37 |
is not the reason for the delay. I would not like to see another |
38 |
factor due to a sandbox which is perhaps negligible on a fast system. |