2) yum-plugin-fastestmirror solves this problem.
3) I think we all upgraded from 14.4k modems a few years ago.
Dan
On Mon, Apr 9, 2012 at 8:35 PM, John Reiser <jreiser@xxxxxxxxxxxx> wrote:
On 04/09/2012 07:18 PM, Dan Mashal wrote:
> As I said in the meeting let's just deprecate it [in favor of yum+network].
The problems I have seen with using only yum+network to perform a distro
version upgrade are:
1. It's a poor idea to be running almost anything else on the box
at the same time as a distro version upgrade. It is quite likely
that an app will encounter difficulties because of mismatched versions
of the components on which it relies. [For instance, I've run across
situations where software-initiated reboot *hangs* after distro version
upgrade; I had to push the reset button.] Thus single user mode should
be considered a requirement for distro version upgrade via yum+network,
although often it happens to work in multi-user mode if the box
is "otherwise idle".
2. yum is stupidly slow about collecting the upgrade .rpms.
First there is downloading itself: yum downloading [of any kind]
is single threaded. Often this wastes 30% to 50% of available
bandwidth (at the server and/or in the pipe.)
A close-to-optimal strategy for typical cable modem ISP is:
1. Sort the download list by size of file to be downloaded.
2. Run two parallel threads. The first thread downloads
from large to small, the second from small to large.
Stop when the threads meet somewhere in the "middle".
[Debian has a two-thread download for "apt upgrade". It does not
use the optimal strategy, but it is still effective.]
Second, yum does not download the remaining .rpm (whose .drpm
are not available) while it is reconstituting the other .rpm
from .drpm. The waste can be significant for the common case
when there are enough .drpm for some large .rpms (kernel,
libreoffice-*, etc.)
3. If distro version upgrade via yum+network fails (power failure,
network failure, configuration failure, operator error, ...),
then you have a big mess.
The .rpm are not saved, so re-downloading might be substantial.
If an expert is not available for hands-on analysis and repair,
then a fresh install might be the best choice to achieve
shortest down time.
Thus effective downtime can be reduced substantially if preupgrade
manages to parallelize the collection of the anticipated .rpms
(download .drpm and .rpm, reconstitute .rpm from .drpm)
with normal multi-user operation of the machine under the old
distro version.
--
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
