On 07/11/2018 04:37 PM, Kevin Fenzi wrote: > 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 <mizdebsk@xxxxxxxxxx> 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. I think it's unsafe only in the case of on-disk consistency, so across VM reboots. I _think_ over a single run of a VM it's safe, which may describe koji usage. I know rjones has looked deeply at qemu caching methods for use in libguestfs so maybe he can comment, CC'd - Cole _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx/message/Z7WFGD3GD5ZWJNSEB3ZG63GJAYT2HR67/
