At 03:05 -0400 Ingo Molnar wrote:
The biggest rpm we have currently is 40 MB, and the average package size 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 rpm -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). Also, 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!
Matt