On Wed, Jul 11, 2018 at 12:26:01PM -0700, 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? We could try this in staging I suppose and have koschei run a
> ton of builds to see what breaks...

The effects of fsync are impossible to see unless you hard-reboot the
machine. (OK, strictly speaking, you can time the fsync call, but let's
ignore that). I'd be more worried about some side-effects of the way
that nosync is implemented with a LD_PRELOAD. I wonder if it wouldn't be
more robust to use nspawn's syscall filter to filter the fsync calls.
(If nspawn is already used by koji, not sure.)

Zbyszek

> 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?
_______________________________________________
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/7O7RRUGTIPDZH5AG2AMOBQ42PCVEB6IM/

Reply via email to