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