On Mon, 06 Oct 2014 09:07:33 -0400
Stephen Gallagher <sgallagh(a)redhat.com> wrote:
The deltarpms were meant to serve two purposes
1) (lesser) Address the needs of users in developing countries (where
Fedora is fairly popular) and bandwidth concerns are very
considerable. Many of these users have connections that are either
metered or extremely slow, so deltarpms provides a way to get the
data to them more economically. This of course can be handled with a
non-default option, so we can talk about making that more
discoverable if we disable them by default.
2) (Major) Deltarpms significantly (Kevin, can you comment with
numbers?) reduces the load on the Fedora update servers and mirrors,
thereby reducing hosting costs as well as increasing the efficiency of
the available bandwidth (since smaller downloads mean you will be
tying up the line for a shorter amount of time).
I don't recall this ever being a reason. (I could be wrong).
I think this actually is worse for mirrors in some ways. They have to
mirror a bunch more files and take up space (which is very dear to
mirrors). It does get them less BW used, but most mirrors are on big
links and don't really notice.
It's definitely worse for releng. Generating drpms takes a long time
and delays things like updates pushes or composes.
It would be nice to see if we can find ways to improve the
performance
of the deltarpm reconstruction instead. Much of the time is spent on
compression/decompression tasks which *should* be massively parallel;
we should be able to speed this up by taking advantage of additional
cores (and hyperthreading) on the system, for example. Another option
might be not to bother recompressing the RPMs but instead just
install an uncompressed RPM (and possibly recompress it out of band
if we needed to keep it in the cache).
Folks wanting to do so are welcome to help out...
Get to coding. ;)
kevin