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