| 1 |
Rich Freeman <rich0@g.o> wrote: |
| 2 |
>> |
| 3 |
>> For containers, at least a dozens of binds are minimally required |
| 4 |
>> (/usr /proc /sys /dev ...). |
| 5 |
> |
| 6 |
> I wouldn't be surprised if it works with a single bind mount with |
| 7 |
> /proc and /dev and so on mounted on top of that. |
| 8 |
|
| 9 |
Either you start with a writable tree and bind-mount some directories |
| 10 |
non-writable or the opposite way. Either way, a dozen or so bind-mounts |
| 11 |
are minimally necessary. |
| 12 |
|
| 13 |
> You say "not even a bind" as if that is a benefit. |
| 14 |
|
| 15 |
In case the "non-scaling" argument has not become clear, |
| 16 |
I try to visualize it by a table: |
| 17 |
|
| 18 |
| "simple" | "fine grained" |
| 19 |
---------+----------------+------------------- |
| 20 |
Overlay | 1 mount | 1 mount |
| 21 |
---------+----------------+------------------- |
| 22 |
Container| 10? bind mounts| 1000? bind mounts |
| 23 |
|
| 24 |
> Honestly, you can't really claim that overlayfs is superior to bind |
| 25 |
|
| 26 |
Correct. If the number of bind mounts really has no influence on the |
| 27 |
file operations in the corresponding part of the tree - e.g. if there |
| 28 |
is really a clever hashing of bind mounts - the above table does not |
| 29 |
indicate any scaling problem. |
| 30 |
|
| 31 |
We are at a point where some kernel source code inspection (or at the |
| 32 |
very least serious benchmarking, preferrably with a slow and low-memory |
| 33 |
machine) is needed before we can continue the discussion in a serious |
| 34 |
way. I do not have the time for this currently. |
Archives