Keeping your Fedora installation up to date can become a problem if your ISP imposes a strict datacap or if you’re stuck with only an expensive mobile data connection. Here are a few tricks for lowering Fedora’s system update bandwidth requirement.
Uninstall unused programs
This may seem obvious but if you uninstall programs and packages that you’re not using; then they’ll no longer require any network resources to keep up to date.
Unsure where to start? Go through your programs and remove all the ones you’ve never opened or not opened more than once. Do you need three instant messaging programs and four web browsers?
Enable low-savings delta updates
Fedora introduced delta update packages (“Delta RPMs”) in Fedora 22. Delta updates only download the bits of a package that chanced from the installed version rather than the full package. This can save significant amounts of bandwidth, depending on what packages you’ve installed.
By default, Fedora will download a delta update package over a full update package when the delta is at least 25 % smaller than the full package. This logic is applied regardless of the actual savings, so it could be 1 KB or 1 GB dependent on the page.
I compared the delta update packages to the full update packages available in Fedora 25’s main update repository on . 72 % of all delta updates met the 25 % savings requirement. By dropping the minimum saving requirement to 10 %, it takes this number up to 94 % of all updates. You can change the percentage saving required for a delta update to be used by setting the deltarpm_percentage option in /etc/dnf/dnf.conf to e.g. 90 (which changes the requirement from at least 25 % smaller to 10 % smaller).
But are these smaller savings worth anything? At the time I made the repository comparison, the mean savings in the 75–90 % band saved a mean of 607 KB per package with a median of 52 KB. This may not sound like much, but actual savings per package can vary from 0,5 KB to 5 MB based on what packages you’ve installed. If you’re paying by the megabyte, it all adds up! Historical data from Fedora 24 shows delta updates saving as much as 400 MB on a single package!
The drawback with using delta updates are that the system needs to sacrifice extra CPU time to process delta updates compared to full updates. If bandwidth savings is your main concern, then you may want to accept delta updates with smaller savings.
Multiple computers? Setup a caching proxy!
If you’ve got more than one computer running Fedora on your network, then you can cut the bandwidth requirement for keeping both systems up to date in half by configuring a web proxy.
A web proxy will act as an intermediary between your Fedora instances and the public internet. When new packages are downloaded on one machine, they’ll be kept in the local cache on the proxy so that the secondary machine. If the two have the same packages installed and use the same repository mirrors, then your bandwidth usage should be cut in half!
Configuring a web proxy is out of scope for this article. Squid is a popular choice on Linux servers. Note however, that any HTTP caching proxy should do the job without any special configuration needed to work on RPM packages.
To use a caching proxy in dnf, set the proxy option in /etc/dnf/dnf.conf to the URL of your caching proxy.
If you don’t intend to use a proxy server, you can benefit from adding fastestmirror=True to the configuration file instead. This option will try to determine which of the available mirrors is the fastest.
Throttle download speeds
Trying to stream a video while dnf is updating your system? You can configure dnf to throttle its bandwidth usage if you’ve some information about the expected available bandwidth.
To throttle bandwidth used for updates, set the throttle option in /etc/dnf/dnf.conf to e.g. 2M (2 Mb/s). The value is in bytes per second, and you can use the suffixes ‘k’, ‘M’, and ‘G’.
Check for updates less frequently
One strategy that can reduce update overhead a little is to check for updates less often. By default, repository metadata is considered fresh for two days, yet it will be automatically updated every hour (by the dnf-makecache.timer systemd unit). You can extend this time by increasing the cache expiration time. This isn’t recommended for systems with high security requirements.
To check for updates less often, set the metadata_expire and the metadata_timer_sync options in /etc/dnf/dnf.conf to e.g. 172800 (2 days in seconds).