Subject: qbittorrent: file creation on startup creates huge loadavg spike
Date: Fri, 22 Nov 2013 20:00:56 +0000
Package: qbittorrent
Version: 2.9.8-1
Severity: normal
the previous version was absolutely fine. this current version performs
extremely badly. basically what happened on the previous version was that
a sparse file was created. this version however does something incredibly
stupid: they create an initially-blank but full-sized file. as that can
sometimes involve writing out a 1gbyte or a 4gbyte file it absolutely
hammers any system, rendering it completely unusable for several seconds
due to the I/O overload.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages qbittorrent depends on:
ii geoip-da 1.4.6.dfsg-17 IP lookup command line tools that
ii libboost 1.49.0-3.2 filesystem operations (portable pa
ii libboost 1.49.0-3.2 Operating system (e.g. diagnostics
ii libc6 2.17-3 Embedded GNU C Library: Shared lib
ii libgcc1 1:4.7.2-5 GCC support library
ii libqt4-d 4:4.8.5+git121-g2a9ea11+dfsg1-2 Qt 4 D-Bus module
ii libqt4-n 4:4.8.5+git121-g2a9ea11+dfsg1-2 Qt 4 network module
ii libqt4-x 4:4.8.5+git121-g2a9ea11+dfsg1-2 Qt 4 XML module
ii libqtcor 4:4.8.5+git121-g2a9ea11+dfsg1-2 Qt 4 core module
ii libqtgui 4:4.8.5+git121-g2a9ea11+dfsg1-2 Qt 4 GUI module
ii libssl1. 1.0.1e-3 SSL shared libraries
ii libstdc+ 4.7.2-5 GNU Standard C++ Library v3
ii libtorre 0.15.10-1+b1 C++ bittorrent library by Rasterba
ii python 2.7.3~rc2-1 interactive high-level object-orie
qbittorrent recommends no packages.
Versions of packages qbittorrent suggests:
pn qbittorrent-dbg <none> (no description available)
-- no debconf information
Reply sent
to Theodore Ts'o <[email protected]>:
You have taken responsibility.
(Tue, 31 Dec 2013 06:33:08 GMT) (full text, mbox, link).
Subject: Re: e2fsprogs: Seems to be hanging and then is suddenly finished...
Date: Tue, 31 Dec 2013 01:30:13 -0500
On Fri, Nov 22, 2013 at 09:40:26PM +0100, Manuel Bilderbeek wrote:
> I don't know whether you can do something with this report, but I'll
> file it anyway.
>
> Today I had an fsck on my main (ext3) partition. It's a rather large
> partition (500GB), so it takes a while. It progressed slowly (with
> irregular speeds), but at 33.9% it stayed for about 15 minutes after
> having done about 10-15 minutes on the first 33.9%. Then I looked away
> for a few minutes and I saw my login-screen. So it had suddenly
> finished.
At 33.9 percent it would have been checking inodes in the inode table.
Assuming you are using the textual completion bar (as opposeed to some
fancy-shamcy graphical completion bar, which I don't think Debian
supports), there's really nothing that can go wrong. At one point, I
believe Ubuntu had some scheme where it was getting the completion
information and displaying it on the graphical init screen. If that
is hanging for some reason, that would be a bug in the fancy graphical
boot up display system, and it's not a bug in e2fsprogs. You'll need
to figure out what graphical boot up system you are using, and file
your bug against that.
If you are seeing a textual completion bar, i.e, something which
looked like this:
/dev/lambda/backup: |============== - 28.4%
Then the only explanation I can think of is either a very badly
corrupted file system (but then you would have seen lots of error
messages scrolling buy), or some kind of hardware fault.
In any case, there really isn't anything I can do about this, so I'm
closing the bug report.
Regards,
- Ted
Subject: Re: e2fsprogs: Seems to be hanging and then is suddenly finished...
Date: Tue, 31 Dec 2013 10:51:55 +0100
Hi,
On 31-12-13 07:30, Theodore Ts'o wrote:
> If you are seeing a textual completion bar, i.e, something which
> looked like this:
>
> /dev/lambda/backup: |==============
- 28.4%
>
> Then the only explanation I can think of is either a very badly
> corrupted file system (but then you would have seen lots of error
> messages scrolling buy), or some kind of hardware fault.
>
> In any case, there really isn't anything I can do about this, so I'm
> closing the bug report.
I was looking at the textual completion bar and there were no errors
shown on the screen during the long delay.
I am not experiencing any hardware faults.
However, I understand there's not much you can do...
--
Kind regards,
Manuel
Acknowledgement sent
to bruno zanetti <[email protected]>:
Extra info received and forwarded to list. Copy sent to Christian Marillat <[email protected]>.
(Mon, 07 Mar 2022 08:21:03 GMT) (full text, mbox, link).
AFAIK there are two possible reasons for this behaviour:
1) In Preferences->Download the option 'Pre-allocate disk space for all
files' is checked (but that's not the default).
2) The option above is not checked but the download folder is within a
filesystem that doesn't support sparse files (at least on Linux) like FAT32
and exFAT. Assuming that sequential download is not checked, when a torrent
piece located GB away from the file beginning is received, the file has to
be extended by physically writing zeros to seek to that position and write
the piece.
When downloading to filesystems with sparse file support (like ext4 for
example) I could not observe such I/O overload, even with file
preallocation (at least with recent versions of libtorrent-rasterbar).
OTOH the issue is still present for downloads to certain filesystems (i.e.
FAT32, etc) and can cause severe performance issues especially with slow
storage.
Regards
BZ
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.