On 07/11/2018 09:26 PM, Kevin Fenzi wrote:
> On 07/11/2018 10:53 AM, Mikolaj Izdebski wrote:
>> On 07/11/2018 07:31 PM, Andrew Lutomirski wrote:
>>> On Wed, Jul 11, 2018 at 10:08 AM, Mikolaj Izdebski <mizde...@redhat.com> 
>>> wrote:
>>>>
>>>> The slowest parts of setting up chroot is writing packages to disk,
>>>> synchronously. This part can be speeded up a lot by enabling nosync in
>>>> site-defaults.cfg mock config on Koji builders, setting cache=unsafe on
>>>> kvm buildvms, or both. These settings are safe because builders upload
>>>> all results to hubs upon task completion. With these settings chroot
>>>> setup can take about 30 seconds.
>>>
>>>
>>> I don't suppose this could get done?
>>
>> I proposed this a few years ago, but the answer was "no".
> 
> I think the reason why releng didn't want to do that is because we don't
> want to trade speed for reliability. True, we don't care if a machine
> crashes in the middle of a build (because another one will take it after
> the crashed one comes back), but we don't want to change anything that
> might affect the actual build artifacts.
> 
> So, are we sure that nosync (disabling all fsync calls) doesn't change
> the builds being made? What about test suites for packages that
> specifically call fsync? They would always pass even if there was a
> problem?

nosync is used by mock only for running dnf(/yum). It's not used for
rpmbuild nor runroot, so it won't affect package tests. It could
theoretically affect scriplets ran during package installation, but I've
been using nosync in all my Koji instances for a few years and I didn't
see any problems. Nosync is used in Copr and I didn't get any reports
about it breaking anything. Recently, to test the change in subject,
Igor Gnatenko did a few Fedora rebuilds a Koji set up by me, of course
with nosync enabled, and I didn't see any problems related to nosync either.

> We could try this in staging I suppose and have koschei run a
> ton of builds to see what breaks...

I would really like that.

> I don't see the cache=unsafe anywhere (although the name sure makes me
> want to enable it for official builds let me tell ya. ;) Can you point
> out more closely where it is or docs for it?

cache=unsafe is documented at [1]. (Basically, in virt_install_command
you append ",cache=unsafe" to --disk parameter, next to "bus=virtio".)
It makes buildvmhost cache all disk operations and ignore sync
operations. Similar to nosync, but does not work on buildhw, works on
virthost level, applies to all operations, not just dnf.

[1]
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/virtualization_tuning_and_optimization_guide/index#sect-Virtualization_Tuning_Optimization_Guide-BlockIO-Caching


-- 
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RALVWM2VNYCPEOFRGDSYYP55CJ22O2TE/

Reply via email to