On 5/12/20 11:22 PM, Michał Górny wrote:
> On Tue, 2020-05-12 at 13:18 -0700, Zac Medico wrote:
>> On 5/12/20 12:28 PM, Michał Górny wrote:
>>> W dniu wto, 12.05.2020 o godzinie 10∶05 -0700, użytkownik Zac Medico
>>> napisał:
>>>> On 5/12/20 3:39 AM, Michał Górny wrote:
>>>>> I'm sorry but I was asking of a more high-level implications.
>>>>> I presume that this means that more than files of more than one
>>>>> package
>>>>> can be merged simultaneously.  However:
>>>> No, an exclusive lock must be held on vardbapi._fs_lock for this.
>>>> This
>>>> is currently required at least to guarantee that access to the config
>>>> memory file is serialized (config memory is the thing that emerge
>>>> --noconfmem disables, but --noconfmem does not disable this lock).
>>>> We assume that it's probably not worthwhile to try to merge files for
>>>> more than one package at a time, since that would cause them to
>>>> compete
>>>> for IO bandwidth.
>>>>> 1. Are collisions handled correctly then?  i.e. if you start
>>>>> installing
>>>>> A, and then B, and the two packages collide will portage fail
>>>>> before
>>>>> starting to install any file from B?
>>>> There are no guarantees here. However, the risk is minimal, since
>>>> it's
>>>> unlikely that a file collision of this sort would occur. file
>>>> collisions
>>>> are a QA problem that is generally detected and corrected log before
>>>> we
>>>> would encounter a collision of this sort.
>>>>> 2. Are preinst/postinst phases called simultaneously or serialized?
>>>> They're serialized.
>>> Now I'm lost here.  Could you try to explain to me, without getting
>>> into the deep technicalities, how parallel-install achieves better
>>> speed or at doing what is non-parallel-install so slow?
>> It allows preinst/postinst/prerm/postrm phases to run for one package
>> while files are concurrently being merged or unmerged for another
>> package. This makes it possible to approach saturation of IO bandwidth.
> Doesn't this imply that programs run in these phases could fail if
> Portage is simultaneously replacing their files?

We've got the same potential issue with emerge --jobs, but we use the
dependency graph to schedule merges such that our dependencies do not
mutate underneath us.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to