On 5/12/20 3:39 AM, Michał Górny wrote: > W dniu wto, 12.05.2020 o godzinie 01∶40 -0700, użytkownik Zac Medico > napisał: >> On 5/11/20 10:54 PM, Michał Górny wrote: >>> W dniu nie, 10.05.2020 o godzinie 21∶32 -0700, użytkownik Zac >>> Medico >>> napisał: >>>> The feature enables finer grained locks for install operations, >>>> and >>>> everyone agrees that it's safe to enable by default. >>> >>> Who's 'everyone' and where's their analysis of the problem? >>> The manpage doesn't really help understand what this does, exactly. >> >> Before parallel-install there was just one big lock, so only one >> package >> slot could enter the merge/unmerge state at a given time. >> >> With parallel install, there are a few finer-grained locks that come >> into play. [...] > > 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. -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature
