On 07/11/2018 12:57 PM, Mikolaj Izdebski wrote:
> 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'd say open a releng ticket on it and we can track it there?
This sounds like it might be worth doing...


>> 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

Ah, I see at the vm level. Yeah, I don't think this would be very much
of a win for us. The x86_64 buildvm's have all their storage on iscsi,
the arm ones have their storage on ssd's. I suppose it could help the
ppc64{le} ones, they are on 10k sas drives. I'm pretty leary of enabling
anything called 'unsafe' though.

kevin


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
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/6PN6UFN5FZXLOBVHKN2PSIHBVKITFNUJ/

Reply via email to