Debian style net-install ISOs (from FudCON Raleigh)

chasd chasd at silveroaks.com
Wed Jan 30 16:39:47 UTC 2008


> John Reiser wrote:

>> Les Mikesell wrote:
>>
>> Reasonable proxy behavior would mostly fix that.
>
> A base + software development install for x86 is about 3GB on disk,
> or 1.5GB on install media.  Many proxies don't cache that much,
> so the savings usually are not so large.

To get an idea of how this relates to the _default_ Squid settings :

#Default:
# cache_dir ufs /var/spool/squid 100 16 256

That 100 in the above config line means 100 MB of storage maximum.
The "ufs" in that config line means if squid is blocked on disk I/O  
it will not attempt to cache any other requests until unblocked.  
There are other options, but that is the default. If you have your  
squid cache on an ext3 partition ( the default ) there is quite a bit  
of blocking for the kjournald. Using ext2 performs much better.

#Default:
# maximum_object_size 4096 KB

I think that line is obvious, it means a lot of RPMs won't be cached  
at all.

I won't get into the specific settings for determining what gets  
purged from the cache as new requests roll in. Basically, the default  
settings are more likely to purge large files ( most RPMs ) in order  
to allow many small files to remain cached.

So the _default_ squid settings are almost worthless for caching RPMs  
either for updates or installs. That is not to say that squid could  
not have a configuration optimized for caching RPMs. However, for  
many people it is much easier to install InstantMirror or something  
like it than learn the ins and outs of squid configuration and tweak  
those settings. You will get better performance easier with an actual  
local mirror.

Admins in larger organizations are more likely to spend the effort to  
set up a mirror on their local network, or even twiddle with cache  
settings if that is the solution best for them. Anything that can be  
done to encourage less experienced or less clueful admins to set up  
local mirrors is a Good Thing. At the very least it improves the  
update / install experience and reduces stress on internet mirrors. I  
can't think of any negatives to local mirrors off the top of my head.


Charles Dostale




More information about the fedora-devel-list mailing list