At 03:05 -0400 Ingo Molnar wrote:
The biggest rpm we have currently is 40 MB, and the average package
is 1.4 MB. More than half of the total rpm size is in rpms that are
smaller than 10 MB. With a 128 MB recommended RAM size this should be
problem-free from a caching point of view. Maybe a special rule could be
added, to not pre-cache RPMs with a size larger than RAM_size/4.
Maybe "pre-cache until size > [some threshold]" ?
also, if the caching is done by copying the next rpm to HD while the
-i of the previous one is running then even if trashing happens, it will
happen on the HD level, not on the CDROM level - and it's the CDROM that
is the fundamental bottleneck of installs.
Yes.. copy RPMs to a tmpfs volume. This would possibly depend on the
target swap having been activated to prevent things going horribly wrong.
ext2/ext3 only speeds up the HD access (by a very small amount).
ext2/ext3 mostly differs in CPU overhead not IO overhead - and the
install-to-hd process is mostly limited by IO latencies (disk seeks).
I was thinking that ext3 writes couldn't return until metadata had been
committed to real media, and that by aggressively write-caching ext2 might
not need to. So, this is a different kind of I/O latency (one which may
well be triggered by %post scripts). But if it was tried with no obvious
performance gain, that is more pertinent than my guesswork!