Hey all,

Running 2.1.4 (same with 2.1.3) in PCLinuxOS, saving files to a FAT32 formatted partition on an external drive. Using a FAT32 so all O/S on LAN can access.

When downloading large DVD iso, the File Allocation part of KTorrent beginning the file takes absolutely forever (30 minutes+ when I stopped it.)

If I start the file with uTorrent, allow it to write one piece of each large file, thereby allocating space, then import into KTorrent... no problems.

Any ideas? I'm having to start in uTorrent, then import/hash check in KTorrent.

How big was the iso image ?

My guess is that the USB interface is the bottleneck here (assuming the harddrive is connected via an USB interface).

Maybe we should just add an option to disable preallocation.

George,

I don't think it's USB alone. The iso is a full DVD distribution, a 4.3 GB iso.

If I use uTorrent or Azureus to write the file initially, they do so, allocate, and set off and run perfectly. If I use KTorrent to import the file once another client has done the initial open, it Hash Checks, allocates /tmp, and goes off and running. This works even if, say, I have a DVD, with several .VOB files, and even one 'piece' of each VOB is written, KTorrent imports it with nothing more than the Hash Check and /tmp allocation.

But if I initially load a large file into KTorrent, I get this issue, every time.

For any torrent over, say, 1GB, I end up beginning in another client, then switching to KTorrent once all parts are at least partially written (allocated.)

I tested a kubuntu DVD yesterday (was about 3.4 GB) on a FAT partition, the preallocation was done in a couple of minutes, certainly not half an hour.

That's why I was thinking that the USB interface was the bottleneck.

If you go to the file in a shell or in a file manager, do you see the file growing when KT is preallocating ?

Oi.

I can't really make it from the source.

What does normal preallocation use and what does full filesystem-agnostic ("basic" in the config menu) preallocation use? I'm asking about system functions/algorithms.

George wrote:I tested a kubuntu DVD yesterday (was about 3.4 GB) on a FAT partition, the preallocation was done in a couple of minutes, certainly not half an hour.

I stopped it at 30 minutes, it wasn't done!

That's why I was thinking that the USB interface was the bottleneck.

OK, so why does uTorrent not behave this way running under Wine?

Why do BitTornado, Azureus, Mainline and Opera not do this, over the same USB, even when available options to pre-allocate all files are set?
Azureus does take about 3-4 minutes for a 4 GB data set, the rest are instantaneous.


I apologise for not being tech savvy enough to go poking about in a console to see if the file grows. I'll simply allocate using another client, for now.

lucke wrote:Oi.

I can't really make it from the source.

What does normal preallocation use and what does full filesystem-agnostic ("basic" in the config menu) preallocation use? I'm asking about system functions/algorithms.

The filesystem specific is only implemented for XFS. The basic one just writes every byte of the file. Normal uses ftruncate.

You can also use posix_fallocate for the basic one.

stevenofnine wrote:

George wrote:I tested a kubuntu DVD yesterday (was about 3.4 GB) on a FAT partition, the preallocation was done in a couple of minutes, certainly not half an hour.

I stopped it at 30 minutes, it wasn't done!

If the file doesn't grow, we know the allocation is stuck somewhere.

I apologise for not being tech savvy enough to go poking about in a console to see if the file grows. I'll simply allocate using another client, for now.

You can use any file manager to go see if the file is growing, no need to poke around in a console

Btw, there is some workaround for resizing files in libtorrent (the one from rtorrent) source (src/data/socket_file.cc). I don't know whether that would apply to ktorrent too?

Hmm, this posix_fallocate, maybe we should give that a try instead of ftruncate.

posix_fallocate is more of a replacement of manual zeroing.

My previous message should read "resizing files on FAT". Have a look at that, George, maybe that's the solution to those FAT problems.

It seems that posix_fallocate does a full preallocation. So I guess we can use that (if it is available) for our basic full disk preallocation.

http://libtorrent.rakshasa.no/ticket/39

lucke wrote:posix_fallocate is more of a replacement of manual zeroing.

My previous message should read "resizing files on FAT". Have a look at that, George, maybe that's the solution to those FAT problems.

We do the same thing as them, seek to the end of the file and then write one byte.