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.
We certainly should check this.
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.
In that case the filesystem should crap out on a write system call. Which should normally result on KT stopping the download.
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.
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.
>you use same libtorrent, yes? No. KTorrent is not libtorrent based, we have our own library written from scratch.
Created attachment 16848 [details] Disk usage reported before starting KTorrent
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.
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.
See also Bug 134822 (Disable download when disk space drops below X MB)
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