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