Re: [HEADS UP] Removal of GCC from the buildroot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux