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. -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature
