[PATCH] autocache patch for mock

[Michael E Brown]

Thanks for the feedback!

On Tue, 2006-05-16 at 22:06 -0500, Jason L Tibbitts III wrote:
> OK, since I do a bunch of builds I just had to try this out.  It took
> me a while to get building again after moving from mock 0.4 to 0.5;
> I'm still not sure where the buildsys-build package is supposed to
> come from, so I just built the spec I found in mock CVS and stuck it
> in my local repo.

To get my stuff working, I changed the config:
	config_opts['chroot_setup_cmd'] = 'groupinstall build build-minimal
build-base'

This emulates the old behaviour. It is a bit easier for now than
building the spec, especially since it won't work for my suse builds
yet.

> 
> Basic summary: this saves me 30 seconds per build; the time goes from
> 2:40 to 2:10 when building a basic package (perl-Expect) which has
> only one dependency outside of base.  These timings are stable and run
> cache-warm.

I tested just 'init' of the buildroot. The timings went from 2:30 down
to :13 with warm cache on my machine. Of course first build of cache
takes longer. From my experience, bzip2 gets much better compression
than gzip, and since you are IO bound, doing less IO (smaller cache)
should improve the timings. (see next point)

> 
> I'm building on a dual core quad socket Opteron 880 (2.4GHz) machine
> with 16GB of RAM; disk is a plain throwaway 250GB Western Digital
> connected via SATA to an onboard SiI 3114 controller.  The machine is
> otherwise idle.  It has sufficient memory to cache pretty much
> everything involved in the build process.
> 
> Things are mostly IO bound on this machine, except for unpacking the
> cached buildroot which is completely CPU bound.  I think that
> switching to gzip might help.

I'll work on that next. I'll make tar look at the file extension and
switch between bzip2/gzip/no-compression.

> 
> Of course, building the cache takes some time; bzip is just incredibly
> slow.  Time for a build after deleting the cache file is 5:43.  Again,
> gzip would probably help; bzip2 is just so slow.
> 
> I noticed one issue: tar is traversing proc.  I thought I saw a patch
> where it was called with -l (--one-file-system) which would prevent this:

Thanks! That should help a bit, I'll make this change to mock-helper.c.

> 
> tar: root/proc/acpi/event: Cannot open: Device or resource busy
> tar: root/proc/irq/11: file changed as we read it
> tar: root/proc/irq: file changed as we read it
> tar: root/proc/sys/dev/scsi: file changed as we read it
> tar: root/proc/sys/dev: file changed as we read it
> tar: root/proc/sys/net/ipv6/neigh/default: file changed as we read it
> tar: root/proc/sys/net/ipv6/neigh: file changed as we read it

I'll send a new patch shortly.
--
Michael