[ https://ovirt-jira.atlassian.net/browse/OVIRT-910?page=com.atlassian.jira.pl... ] Barak Korren updated OVIRT-910: ------------------------------- Description: After implementing speedup improvements for mock_runner.sh (Specifically enabling it to deploy the chroot by extracting a tarball as opposed to installing it with yum every time), I started monitoring run times for vdsm check_patch jobs. I've noticed that jobs that are running on the old slaves (fc24-vm*) seem to initialize mock faster then ones running on new slaves (vm*) - 17seconds vs 57 seconds respectively. I suspect this may be because the older slaves have a different FS mounted on /var/cache/mock was: After implementing speedup improvements for mock_runner.sh (Specifically enabling it to deploy the chroot by extracting a tarball as opposed to installing it with yum every time), I started monitoring run times for vdsm check_patch jobs. I've noticed that jobs that are running on the old slaves (fc24-vm*) seem to initialize mock faster then ones running on new slaves (vm*) - 17seconds vs 57 seconds respectively. I suspect this may be because the older slaves have a different FS mounted on /var/lib/mock

mock_runner.sh seems to run slower on newer slaves --------------------------------------------------

Key: OVIRT-910 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-910 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Jenkins Reporter: Barak Korren Assignee: infra

After implementing speedup improvements for mock_runner.sh (Specifically enabling it to deploy the chroot by extracting a tarball as opposed to installing it with yum every time), I started monitoring run times for vdsm check_patch jobs. I've noticed that jobs that are running on the old slaves (fc24-vm*) seem to initialize mock faster then ones running on new slaves (vm*) - 17seconds vs 57 seconds respectively. I suspect this may be because the older slaves have a different FS mounted on /var/cache/mock

-- This message was sent by Atlassian JIRA (v1000.610.2#100023)