Proposal: stop holding composes for preupgrade bugs at Alpha and Beta phases
dan.mashal at gmail.com
Tue Apr 10 05:05:12 UTC 2012
1) Yum should be intelligent enough to recognize this
2) yum-plugin-fastestmirror solves this problem.
3) I think we all upgraded from 14.4k modems a few years ago.
On Mon, Apr 9, 2012 at 8:35 PM, John Reiser <jreiser at bitwagon.com> 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
> 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 at lists.fedoraproject.org
> To unsubscribe:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the test