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