Bug 1032541 - [rfe] limiting parallel downloads in low disk space environments
[rfe] limiting parallel downloads in low disk space environments
Status: NEW
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
Unspecified Unspecified
low Severity unspecified
: ---
: ---
Assigned To: rpm-software-management
Fedora Extras Quality Assurance
: FutureFeature, Triaged
Depends On:
Blocks: rel-eng-dnf
  Show dependency treegraph
Reported: 2013-11-20 06:24 EST by Miroslav Suchý
Modified: 2017-01-11 11:18 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Miroslav Suchý 2013-11-20 06:24:08 EST
I very often operate in virtual machines where I have very limited disk space. And something like 1.5 GB of free space in /.

And very often I hit something like this during upgrade:
Total download size: 1.2 GB

So I need 1.6 GB to download all rpm files needed in transaction. But then I need several hundreds of MB to keep old files, because old files are deleted at very end of transaction. And this together is more space then I have available.

So I'm forced to do something like:
yum upgrade a*
yum upgrade b*
yum upgrade kernel*
and then finaly
yum upgrade

It would be nice if dnf can offer to split transaction into several independent transactions. Something like:

Total download size: 1.2 GB
Transaction check. You need 1.9 GB, but only 1.5 GB are available. I can do upgrade in two independent transactions. Do you agree? [Y/n]
Comment 1 Ales Kozumplik 2013-11-20 08:07:58 EST
Hi, thanks for the report, we in fact have something like this planned because of Anaconda. The way this is going to work is that if less than some critical needed amount of memory is available then DNF switches to installing packages one by one.
Comment 3 Ales Kozumplik 2014-09-19 05:37:14 EDT
Giving this (stil valid) issue up for now: doing this properly will require moving to a new, refactored and more flexible RPM backend in DNF and there is currently nobody working on it now. The discussion usually involves plans of improving/updating the current RPM Python API.
Comment 4 Honza Silhan 2014-11-24 14:50:25 EST
Do you still need behavior from comment 1, Anaconda guys?

The original request could be solved by using flexible space in VM or dnf-automatic for smaller regular updates. There's not a big chance to make it happen soon if no more people wanted it.
Comment 5 Miroslav Suchý 2014-11-24 19:43:54 EST
Well dnf-automatic will not help you when you have cloud image, spin up new VM and you will do first dnf-upgrade. Very small cloud instances have 2 or 3 GB for root partition with 70% utilization. And that first upgrade will require 1GB which does not fit.
Comment 6 Honza Silhan 2015-07-20 05:11:01 EDT
This is really hardly to implement feature requiring the big design change in DNF.
Comment 7 Felix Miata 2016-02-10 04:08:32 EST
(In reply to Jan Silhan from comment #6)
> This is really hardly to implement feature requiring the big design change
> in DNF.

That may be, but urpmi has been doing it for years by default, as zypper has had an option to do since long before dnf existed.
Comment 8 Peter Robinson 2016-02-10 05:27:41 EST
In the move over to using live-media-creator for creating live CDs, and hence dnf, we're seeing this is rel-eng related tasks where in some cases we've had to increase the disk size from 10gb to 14gb (and increase of 40%) to get the compose to complete.

Comment 9 Fedora Admin XMLRPC Client 2016-07-08 05:26:02 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 10 Igor Gnatenko 2016-08-12 11:45:27 EDT
This is needed.


Note You need to log in before you can comment on or make changes to this bug.