No more deltarpms by default
kevin at scrye.com
Mon Oct 6 15:31:19 UTC 2014
On Mon, 06 Oct 2014 09:07:33 -0400
Stephen Gallagher <sgallagh at 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. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the devel