Dnia 17-04-2006, pon o godzinie 21:45 -0400, seth vidal napisał(a):
It just means we have to make an additional temp file and compare it
every time. It costs time for the generic case where the files have
changed and are newer. That being the most common case.
The most common case? Maybe
if you use one server only. I use FC5
default config which uses a ton of mirrors. I am downloading "new"
version of the same repo's "primary.xml.gz" every half an hour (with
many versions spread among the mirrors) and other users are doing the
same thing. Yes, I know I can use "yum -C", but I really want to have
the newer data downloaded when I use yum list/yum install (which I do
pretty often), why can't I?
When I think about the cost I see one assembly jlt/jgt (how many CPU
cycles? ;)) to check if a timestamp is less (file is older) and issuing
a "move file" operation from (let's say) repomd.xml.tmp to repomd.xml,
which 1. is handled by kernel and kept in cache for a while, so no
slowup for yum and 2. "download xml.tmp;remove xml;move xml.tmp to xml"
instead of "remove xml;download xml" doesn't cost much more instructions
as I see it.
Oh, and last night I updated updates' cache with the updates at 1:00,
but wanted to download it when I sleep (86 MiB of updates after manually
taking pilot-link from updates-testing - this took over 2,5 hours on my
link), so (stupid me) instead of "yum -C" I did a "yum update" an
hour
later.
Turned out there were three repo versions on the mirrors (with
primary.xml.gz having 122, 130 and 161 "k"B). I ended up doing "yum
clean all; yum update" (with only one repo enabled) for 10 straight
minutes just to see the data I already had over an hour earlier. It also
downloaded megabytes of useless data from the mirrors - to hell with my
link, but it costs the mirrors' bandwidth. All this IS a cost, but
simple "if timestamp2 > timestamp1" isn't.
I'm really not moaning, I can live with that until I get my hands on the
new apt, but I think about the others - why do they have to live with
it? :)
Lam