Score:0

Stops downloading large file after 2GB

us flag

I've had an issue downloading large files where the download halts after each 2GB chunk of data for a while now (possibly from the very start of using Kubuntu).

For example, I am downloading a >8GB file with wget and have had to restart the download three times (with wget -c url_here)

95%[++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++======================================> ] 8,03G 1,82MB/s eta 2m 13s

I've refreshed the system logs (using KSystemLog) before and after to see if it threw some error. But nothing was printed out.

I've also seen the issue here: can't download file of which size is bigger than 2GB but the root cause wasn't discussed or solved.

In an attempt to narrow down the issue, I tried downloading from the same source and network on a Windows laptop and that worked without halting indefinitely. But neither my Kubuntu desktop setup, nor Ubuntu server is able to download >2GB files.

It also happens to the browser and in a Windows VM on my Kubuntu desktop.

I've also noticed torrenting large files work fine. So perhaps it has to do with a download limit per connection?

Here's a bit of generic info that might help:

(base) ab@desktop:~/Downloads$ uname -a
Linux desktop 5.4.0-77-generic #86-Ubuntu SMP Thu Jun 17 02:35:03 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

(base) ab@desktop:~/Downloads$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.2 LTS
Release:        20.04
Codename:       focal

(base) ab@desktop:~$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 63437
max locked memory       (kbytes, -l) 65536
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 63437
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

(base) ab@desktop:~$ lsblk -o NAME,FSTYPE,MOUNTPOINT
NAME   FSTYPE   MOUNTPOINT
loop0  squashfs /snap/core18/2074
loop1  squashfs /snap/snapd/12159
loop2  squashfs /snap/core18/2066
loop3  squashfs /snap/snapd/12398
loop4  squashfs /snap/spotify/46
sda             
└─sda1 ext4     
sdb             
├─sdb1 vfat     /boot/efi
├─sdb2 ext4     /
└─sdb3 ext4     /home
sdc             
└─sdc1 xfs      /run/timeshift/backup

Video demonstration: https://youtu.be/24yO6NxwFgQ

Any ideas on what might be wrong are appreciated.

guiverc avatar
cn flag
Are you sure you have a *fs* that can support >2GB files; ie. could the download be stopping due to disk IO error as the data cannot be saved... What *file-system* are using trying to save the files too? 2GB is one of the limits for certain *fs*
Anton Blomström avatar
us flag
Good question guiverc. I added the relevant info. I'm using ext4 for my home directory, and I ran the download command at ~. I think ext4 is able to handle >2gb files. I'll see if I can make a demonstrative video of what's going on today.
cn flag
It could also be your router :)
Anton Blomström avatar
us flag
Thanks for writing, Rinzwind ^^ I did try to rule that out by using my windows computer to download a >2GB file. I actually tried it again though, and it's doing the same as it does on Ubuntu. Could perhaps be due to using a 4G router, but it's probably not Ubuntu that's the issue then. I'm going to try a few more things. Otherwise, it is how it is.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.