Bug 129686 - Check for full disk before processing new torrents
Summary: Check for full disk before processing new torrents
Status: RESOLVED FIXED
Alias: None
Product: ktorrent
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal with 20 votes (vote)
Target Milestone: ---
Assignee: Joris Guisson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-23 06:39 UTC by Charles Phoenix
Modified: 2007-03-18 22:27 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
Disk usage reported before starting KTorrent (28.71 KB, image/png)
2006-07-02 06:48 UTC, Charles Phoenix
Details
Disk usage reported after starting KTorrent (28.65 KB, image/png)
2006-07-02 07:45 UTC, Charles Phoenix
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Charles Phoenix 2006-06-23 06:39:18 UTC
Version:           2.0beta1 (using KDE 3.5.3, Gentoo)
Compiler:          gcc version 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)
OS:                Linux (i686) release 2.6.15-gentoo-r1

What happened...

The partition is already 99.99% full. A crash. The half torrents I had queued were put under user control and the remaining half (all new) were being processed. The program blindly tries to allocate space and program becomes unresponsive.

A simple check for a full disk, especially if an full disk error just occurred would prevent the above behavior. So I would have expected to get about "disk full" errors to flash on the screen.

A quota limit to default to around 90% of disk space would be a better solution. It is annoying when programs blindly use up space.
Comment 1 Joris Guisson 2006-06-26 20:30:47 UTC
We certainly should check this.
Comment 2 Charles Phoenix 2006-06-30 05:54:04 UTC
An addition to 'full disk' behavior. How space is allocated is not fixed (?) thus I have had KTorrent (and rTorrent) download merrily only to have massive corruption. I appears either there is no 'ran out of space' error being reported.
Comment 3 Joris Guisson 2006-06-30 08:18:55 UTC
In that case the filesystem should crap out on a write system call. Which should normally result on KT stopping the download.
Comment 4 Charles Phoenix 2006-06-30 18:45:19 UTC
I assume the allocation is "penciling in" space; it is pending space usage.

What happened:

There were/are file errors reported for the partition in question; rTorrent ran without interruption from the initial import; no filesystem checks done. When I started rTorrent it did a validation check to pull in partial torrents from KTorrent. At this time the partition was at the 98%+ full state. Every thing appeared to work. Being paranoid I did a validation check when the imported torrent were finished. The corruption was around 80% with a couple of files. I made space on the file system (careful to have space left over); restarted the torrents. No corruption.

Note: There were a few complete downloads with no corruption through the above time frame. Therefore I conclude it is how the files are allocated ("penciling in") causing this problem and somehow two files are writing to the same place without any errors occurring. It never gets to the "crapping out" stage for it thinks there is still space available.

Note 2: There are errors in the kernel log about swapping at the same time frame so I will have to eliminate memory. Sending this now.
Comment 5 Charles Phoenix 2006-06-30 21:12:18 UTC
Opps, that is no file errors were reported from either rTorrent or KTorrent.

Tests done

1) Physical memory okay
2) "Stress test" swap memory, brought it up to 270,000KB launching numerous program. No errors reported.
3) reiser.fsck partition, reported 2 error to the bitmap, fixed

As for the kernel errors, they are all swap page allocation errors and the time frame is when rTorrent (you use same libtorrent, yes?) would have encountered a 100% full partition until I started making space.
Comment 6 Ivan Vasic 2006-06-30 21:19:58 UTC
>you use same libtorrent, yes?

No. KTorrent is not libtorrent based, we have our own library written from scratch.
Comment 7 Charles Phoenix 2006-07-02 06:48:07 UTC
Created attachment 16848 [details]
Disk usage reported before starting KTorrent
Comment 8 Charles Phoenix 2006-07-02 07:45:31 UTC
Created attachment 16849 [details]
Disk usage reported after starting KTorrent

In the first snapshot I am using *46.4GB* on a 40.1GB partition.

Note 1) Using revision 556991.
Note 2) There is 6.3GB free.

I started a 10GB+ torrent by right clicking the torrent. KTorrent started
without any complaint.

The result...

In the second snapshot I am now using *57.0GB* on the same 40.1GB partition. :)

It did not catch the free space error.

After deleting the "allocated" 10GB the 57GB became ~46GB again.


The solution is simple... check for free space, don't assume the library will
do it. No need to do manual allocation in this case. Test for full space
corruption after including the free space check.
Comment 9 Bob 2006-08-09 00:42:45 UTC
Confirming this bug.  I was about to file a report of my own.

Running KTorrent 2.0 rc1 on kubuntu dapper.  ext3 filesystem.

When the drive is full, it tries to keep downloading, and corrupts the files it is attempting to write too.
Comment 10 Tristan Miller 2007-03-10 21:26:51 UTC
See also Bug 134822 (Disable download when disk space drops below X MB)
Comment 11 Ivan Vasic 2007-03-18 22:27:21 UTC
SVN commit 643952 by ivasic:

Added diskspace check when starting torrents. 
Action is now configurable through settings.

BUG:129686
CCMAIL:changelog@ktorrent.org

 M  +213 -154  apps/ktorrent/downloadpref.ui  
 M  +1 -7      apps/ktorrent/fileselectdlg.cpp  
 M  +0 -4      apps/ktorrent/fileselectdlg.h  
 M  +3 -1      apps/ktorrent/pref.cpp  
 M  +4 -0      libktorrent/ktorrent.kcfg  
 M  +289 -164  libktorrent/torrent/queuemanager.cpp