Re: [PATCH v2 00/13] Overlayfs lazy lookup of lowerdata

[Gao Xiang <hsiangkao@linux.alibaba.com>]

On 2023/5/26 10:27, Gao Xiang wrote:
> Hi Giuseppe,
> 
> On 2023/5/26 09:59, Giuseppe Scrivano wrote:
>> Hi Amir,
>>
>> Amir Goldstein <amir73il@gmail.com> writes:
>>
>>> On Thu, May 25, 2023 at 6:21 PM Alexander Larsson <alexl@redhat.com> wrote:
>>>>
>>>> Something that came up about this in a discussion recently was
>>>> multi-layer composefs style images. For example, this may be a useful
>>>> approach for multi-layer container images.
>>>>
>>>> In such a setup you would have one lowerdata layer, but two real
>>>> lowerdirs, like lowerdir=A:B::C. In this situation a file in B may
>>>> accidentally have the same name as a file on C, causing a redirect
>>>> from A to end up in B instead of C.
>>>>
>>>
>>> I was under the impression that the names of the data blobs in C
>>> are supposed to be content derived names (hash).
>>> Is this not the case or is the concern about hash conflicts?
>>>
>>>> Would it be possible to have a syntax for redirects that mean "only
>>>> lookup in lowerdata layers. For example a double-slash path
>>>> //some/file.
>>>>
>>>
>>> Anything is possible if we can define the problem that needs to be solved.
>>> In this case, I did not understand why the problem is limited to finding a file
>>> by mistake in layer B.
>>>
>>> If there are several data layers A:B::C:D why wouldn't we have the same
>>> problem with a file name collision between C and D?
>>
>> the data layer is constructed in a way that files are stored by their
>> hash and there is control from the container runtime on how this is
>> built and maintained.  So a file name collision would happen only when
>> on a hash collision.
>>
>> Differently for the other layers we've no control on what files are in
>> the image, unless we limit to mount only one EROFS as the first lower
>> layer and then all the other lower layers are data layers.
>>
>> Given your example above A:B::C:D, if both A and B are EROFS we are
>> limited in the files/directories that can be in B.
> 
> If my understanding is correct (hopefully), I might ask if it's the
> proposal to pass in multiple composefs manifests (rather than one)
> all together to overlayfs in one shot?

Oh I could see the issue if a composefs manifest works with other
regular underlay layers, such redirect might need a way directly
to data layers instead of any potential underlay layer.