Rich Freeman wrote:
>>
>> | "simple" | "fine grained"
>> -++---
>> Overlay | 1 mount| 1 mount
>> -++---
>> Container| 10? bind mounts| 1000? bind mounts
>
> Except it is more like:
>
>
On Mon, Sep 25, 2017 at 11:27 AM, Martin Vaeth wrote:
> Rich Freeman wrote:
>>
>> I wouldn't be surprised if it works with a single bind mount with
>> /proc and /dev and so on mounted on top of that.
>
> Either you start with a writable tree and bind-mount some directories
> non-writable or the o
Rich Freeman wrote:
>>
>> For containers, at least a dozens of binds are minimally required
>> (/usr /proc /sys /dev ...).
>
> I wouldn't be surprised if it works with a single bind mount with
> /proc and /dev and so on mounted on top of that.
Either you start with a writable tree and bind-mount
On Sun, Sep 24, 2017 at 2:11 PM, Martin Vaeth wrote:
> Rich Freeman wrote:
>> On Sun, Sep 24, 2017 at 4:24 AM, Martin Vaeth wrote:
>>> Tim Harder wrote:
>>>
>>> It is the big advantage of overlay that it is implemented in
>>> kernel and does not involve any time-consuming checks during
>>> norm
Rich Freeman wrote:
> On Sun, Sep 24, 2017 at 4:24 AM, Martin Vaeth wrote:
>> Tim Harder 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 beh
On Sun, Sep 24, 2017 at 4:24 AM, Martin Vaeth wrote:
> Tim Harder 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
Tim Harder wrote:
> On 2017-09-23 19:59, Rich Freeman wrote:
>> A read-only container
>
> I doubt bind mounts will scale
>
> As has been mentioned before, a different way would be to write some
> sort of FUSE fs
The problem with both, containers and FUSE, is performance.
(For containers with thou
