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.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to