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(a)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/...
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