Bad Experience on Unreliable Connections
Opened this issue · 3 comments
for users who have unreliable internet connections rpm-ostree has a very poor experience, including wasted bandwidth.
While it is possible to turn off updates using the "metered connections" option, often, this is not a option, as it is important to maintain a secure system when traveling or in low-economic countries.
Problems:
- Unable to cancel the transfer of a object: canceling must wait until the current object is obtained before cleanly exiting.
- Cache deletes objects that have been successfully downloaded if rpm-ostree dose not cleanly exit.
- No progress for the download of the current object.
- Iterative metadata process gives a false exception of time requirements for download.
- Timeout for changing, dropping, and unstable connections is far-too-long. Leading for very annoying object download stalls; on poor connections leading to a infinite download time.
- Partial and presumable downloads of large objects should be the default.
Expected:
rpm-ostree should be very respectful of user bandwidth. modern cryptographic techniques, (such as a hash-merkel tree), should be used to verify partial downloads; such as what bittorrent provides; there should be (almost) no loss of downloaded data, even when exiting uncleanly.
rpm-ostree should provide clear and accurate data for the progress and speed of the download, downloading all the required meta-data ahead of time in a non-iterative process.
rpm-ostree should use a multi-threaded multi-piece download system with short timeouts and multiple routes, either using bit-torrent directly, or a system that is modeled upon bit torrent for its efficiency and resilience under adverse conditions.
What package requests do you have? It should only be downloading the filelist if you're requesting something by path that falls outside of [/usr]/[sb]in/ (this could also be requested transitively via one of your top-level package requests). The logic for that is shared with dnf (via libdnf).
@jlebon The program that is running is refresh-md, the automated update program. Here on F33 Silverblue.
Ahh right, OK. The refresh-md calls are almost certainly triggered by GNOME Software. Hmm, I think GNOME Software has capabilities for detecting metered connections. If it doesn't recognize it as a metered connection, it's possible you have to label it as such manually? (But also, it's probably safer to disable automatic updates in that case).
I'll have to dig into the download resume bit; all that should be shared with dnf via libdnf/librepo.