Fedora Core brevity vs server upgrades
John Summerfied
debian at herakles.homelinux.org
Tue May 10 01:30:09 UTC 2005
William Hooper wrote:
> Les Mikesell wrote:
>
>>On Wed, 2005-05-04 at 16:04, William Hooper wrote:
>>
>>
>>>Jay Lee wrote:
>>>
>>>
>>>>wgetting
>>>>http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc
>>>>3
>>>>shows a list of possible mirrors and I assume yum randomly selects one
>>>>to use each time (resulting in each request behind a proxy hitting a
>>>>different mirror). What would be ideal is if that url was dynamic
>>>>and returned a single mirror url for yum to use.
>>>
>>>You would loose the ability to fail over to another mirror if something
>>> was wrong with that one URL. Also you would increase load on the
>>>fedora.redhat.com server because it would have to generate this file
>>>for every request rather than serving a static file.
>>
>>On the other hand, if DNS returned multiple addresses for one name,
>>the load would be spread among the sites automatically,
>
>
> Which happens now.
>
>
>>caching proxies
>>would do the right thing,
>
>
> I'm sure that would depend on the proxy and your definition of "the right
> thing". Caching metadata is a hinderence, not a feature.
This morning I updated Linux on eight or so boxes, most on a single LAN,
all remote from me.
Where the machines share an Internet connexion, why would I want them to
refetch the metadata regarding the remote sites? What _I_ want is all
machines to use one mirror, one set of metadata, one collection of packages.
Most of the machines have most packages in common.
So long as the packages describedby the metadata exist, I don't have a
problem with caching the metadata. I perform my software maintenance at
times convenient to me and my users; I don't care a lot if a package has
been replaced in the past few minutes or hours, my next maintenance run
will get it.
>
>
>>you wouldn't have to keep redistributing the
>>mirror list,
>
>
> It's 2K, not that big of a deal.
The current implementation is.
I ran yum, update twice consecutively to quantify this. There were no
updates available at the time.
[summer at echidna ~]$ time sudo yum -y update
Password:
Setting up Update Process
Setting up Repos
base 100% |=========================| 1.1 kB 00:00
updates-released 100% |=========================| 951 B 00:00
Reading repository metadata in from local files
base : ################################################## 2622/2622
updates-re: ################################################## 885/885
No Packages marked for Update/Obsoletion
real 4m5.094s
user 0m23.007s
sys 0m5.761s
[summer at echidna ~]$ time sudo yum -y update
Password:
Setting up Update Process
Setting up Repos
base 100% |=========================| 1.1 kB 00:00
updates-released 100% |=========================| 951 B 00:00
Reading repository metadata in from local files
base : ################################################## 2622/2622
updates-re: ################################################## 885/885
No Packages marked for Update/Obsoletion
real 2m56.149s
user 0m22.863s
sys 0m5.332s
[summer at echidna ~]$
I suspect that most of the improvement in the second run occured because
the disk data was mostly cached.
The nearest equivalent I have using apt-get is a Ubuntu system. On that
system, the second run took less than nine seconds.
If you're being paid to look after these systems, those three and four
minutes are quite a charge - if you cost 100 Currency Units/hour, that's
five to seven CU for each system, each time.
>
>
>>and failing over could be handled by the application (even IE
>>does this nicely so it can't be that hard...).
>
>
> Yum handles fail over now, by going to the next mirror if it contact the
> current one, and going to the next mirror if you hit Ctrl-C.
_I_ have a robustness problem with yum.
I like to use links (not elinks) for some stuff because it does graphics
on framebuffers (and under X), but elinks conflicts with links and
something requires elinks.
Consequently having both causes some conflicts, and yum can't handle it
and won't do any updates.
Using, apt-get I could configure to leave certain packages (eg links and
elinks) alone and it will get on with updating other stuff.
_I_ can and will when it bugs me anough, handle the problem by tracking
elinks source rpm and building my own corrected package.
--
Cheers
John
-- spambait
1aaaaaaa at computerdatasafe.com.au Z1aaaaaaa at computerdatasafe.com.au
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
More information about the fedora-list
mailing list