Preallocation not working in 2.2.0beta2

[microchip]

Hi,

I just compiled qbittorrent v2.2.0beta2 and it seems that, even when enabled, preallocation doesn't do a thing. When loading a torrent, there's absolutely no disk activity to be seen and it starts downloading right after being loaded. In other torrent clients (ktorrent, vuze, etc) there's always disk activity for some time while preallocating

My specs/system

openSUSE 11.1 (64 bit)
Ext3 file system
qbittorrent 2.2.0beta2
libtorrent-rasterbar-devel 0.17.4
QT 4.5.3

I also noticed some odd behavior how it handles trackers. It seems to go through the whole list of tracker and then stops at the first tracker that it can connect to. Other trackers after this one always get the message "Not contacted yet". Is this desirable behavior? I suspect not...

Thanks

[Christophe Dumez (hydr0g3n)]

For the tracker issue, I don't understand. If you are using libtorrent v0.14.7 (You wrote v0.17.4 but I suppose this is not what you meant), it should not go through the whole list unless all trackers are failing.

With libtorrent v0.15 though, it will go through the whole list, even if the trackers are not failing. This behavior is similar to uTorrent. If you have issues with tracker handling, please ask libtorrent author about it because this is not my code: http://code.google.com/p/libtorrent/issues/entry

Regarding the preallocation, I will check my code but first, did you check the hard disk to see if the files were correctly created and it their size is the final expected size? Simply considering hard disk activity is not really a proof that it is not working. Especially because libtorrent uses sparse files to preallocate, it means that it does not actually have to write '0's on the hard disk to preallocate. This is way more efficient and the visual result is the same.

[microchip (neutrino8)]

Hi Chris, (may I call you Chris? :P)

I found out several things since my original report. The libtorrent version is indeed 0.14.7 as you said (I wrote that bug report at 4 in the morning and was not only tired but also distracted on IRC). However, that version came from my distro and I suspect there's something wrong with it. I then went and grabbed the 0.15svn one from the front page of qbittorrent where it offers a link to it. Before compiling it and then compiling qbittorrent, I removed all instances of my distro's libtorrent. The compilation went for both just fine and when I open a torrent it starts to preallocate (I see lots of disk activity) so that seems to be fixed for me. BUT, after preallocation is done and it starts downloading, half a minute later or so, a message pops up and says there's something gone wrong on the disk IO side and immediately halts the torrent. I tried with three other torrents and get the same behavior. So then, I decided to grab libtorrent 0.14.8 and compile it, together with qbittorrent again but before that, I removed everything related to version 0.15svn from libtorrent. Compilation again went fine for both libtorrent 0.14.8 and qbittorrent 2.2.0beta2 and all seems to work now, including preallocation. After trying out a few torrents which carried only a single file, I tried out a torrent which carried three big files in it. When I opened it, I selected to download only the first of the three files but I noticed after clicking OK, it went on to preallocate *all* files - I checked their sizes too and it also took way longer to preallocate even though I selected only one out of the three files... the way I know that is because I compared how long it takes to preallocate the selected file against another torrent which carried only one file but of exactly the same size. The torrent with the multiple files in it where I only selected the first one to download took way longer to preallocate (in total, that torrent carried a load of 2.1GB, the selected file for download was only 700MB big). I've no idea if this is normal behavior for qbittorrent or libtorrent itself (in some torrent client it is, like Vuze for example) but it is not normal behavior in KTorrent. In there, if the torrent carries multiple files and you select only a specific one to download, only that file will be preallocated and the rest will not show on disk. I find this a better way of doing it for the following reason....

Suppose I have a torrent which is 60GB in size, but I only have 40GB of disk space left over. In case I'd only want to download a specific file from it which fits within my 40GB, this will not be possible because it'll start preallocating the whole 60GB instead of only the selected file in the torrent which fits within my 40GB so in the end I won't be able to grab anything form it because it'll run out of disk space before it even finishes preallocation and starts downloading.

About the trackers thing, I'll have to investigate a bit longer. But from what I've seen so far, both using libtorrent 0.14.7 and 0.14.8, when the torrent has multiple trackers, it seems to go through the list (top to bottom) and stops at the first tr...

[microchip (neutrino8)]

Hmmm, strange, I think you may need to discard most of what I said above. When I open now torrent files and preallocation is enabled, it does not trash the disk while preallocating like it did yesterday (I've no idea why it did that yesterday for all torrents I tried). I also now checked to see if those are sparse by comparing the output of "du -s -B1 --apparent-size" and "du -s -B1" and they indeed seem to be so.