How do you enable sparse files?

[mojo-chan]

I'd like to enable sparse file support in qBittorrent. I can't see how to do it though. libbittorrent supports it and there are a few mentions on the forums, but no option for it anywhere. Am I missing something?

[Dayman]

Hello.

Preallocation should be disabled in options.

P.S. Sparse flag is not supported on FAT filesystems and sparse flag is not preserved when moving files between discs.

[mojo]

Thanks. So are you saying that if pre-allocation is turned off then sparse mode is on all the time?

That would explain the terrible performance on my old hard disk. I upgraded to an SSD because it was so bad - downloading at 5MB/sec would cause the RAM cache to fill up as the disk choked and eventually downloads would pause for about five minutes as it emptied out. All is lovely now I have an SSD but HDDs really grind with sparse files.

[Dayman]

Yes, sparse is enabled when preallocation is off.

[mojo-chan]

Thanks, that is both good news and explains why performance was so much worse than uTorrent with sparse files turned off.

[latheofheaven]

Okay, this is my very first post here; I hope I am placing it in the appropriate place (If I had a nickel for every time I had to ask this )  Anyway... Sorry... I just switched over from the Evil UTorrent to this one and it looks great so far!

Looking at your answers here to this thread, I am wondering whether I SHOULD enable 'Pre-allocation' or whether I shouldn't...  That is primarily what I did a 'search' for and came to this thread.

You mention 'Sparse files', which I know NOTHING about.  Since you mention an either / or situation here (if I understand it correctly) Should I enable Pre-allocation of files or should I not?  I am running Win8 and have a fairly fast computer and a fairly fast connection.

I appreciate any suggestions.  I notice that the Pre-allocation of files is NOT checked by default.

Thanks!

[Switeck]

I recommend enabling 'Pre-allocation' for regular hard drives.
However that won't help SSDs very much:
http://qbforums.shiki.hu/index.php/topi ... l#msg12725

Deluge (which also uses libtorrent) has the same problem:
http://forum.deluge-torrent.org/viewtop ... 12&t=36959

[latheofheaven]

I appreciate the reply, thanks!

I don't really understand the information on the threads you included, but I guess I will just follow your recommendation and set it for 'Pre-allocation'.  I ALWAYS use my HDD for DL; I never use my SSD drive for that.

If anyone wishes to elaborate a little bit so that I can understand what actually is going on, that would be great!  I THINK what Pre-allocation means is simply that the client does just that, pre-allocates the FULL size of the torrent on the HDD so that it puts it all in the same place, right?  Rather than scattering it as much across the drive.  Is that correct?  If so, I would GUESS that is what you would want to do.

Now, as far as being able to preview or check a torrent as it is DL, should I choose 'Download first and last pieces first'?  Or, is there any disadvantage to that?

Thanks MUCHO!

[sledgehammer_999]

Let's you have a file 1GB in size.
Pre-allocation: qbt will tell the OS to create a 1GB file on the disk and fill it with zeroes (ie empty data). It will actually take the time to write null data to disk. So depending on the file sizes you'll have first to wait for the files to be fully allocated before downloading.
Sparse files: qbt tells the OS that the create file will have 1GB data in the future but for now it only writes eg 10MB of real data. The OS then writes only those 10MB to disk and specially marks the file to indicate that it is 1GB. So if someone tries to copy it will fill the missing data with zero bytes and the resulting file will be fully allocated.

Basically sparse files allow faster allocation without wasting unused space in expense of fragmented disk space.
(also search google)

[Switeck]

The fragmentation levels of using sparse files is incredibly bad, as the Deluge thread pointed out.

qBT should be writing whole pieces at a time, so the maximum fragmentation should be only very slightly higher than the number of pieces per torrent at absolute worst.

Most SSDs cannot write tiny 16 KB chunks at a time. Instead they have to write in whole blocks of 512 KB or multiples of. (1024 KB, 2048 KB, etc.)
This means to write 512 KB of a torrent to a SSD using tiny 16 KB chunks actually requires 32 separate writes of 512 KB each...or even worse!

[latheofheaven]

Okay, thanks!

So then, what I understand is that by NOT pre-allocating space, other than whatever resulting fragmentation, basically the DL's happen faster because it DOESN'T have to pre-allocate the entire size first, right?

So, at the cost of whatever fragmentation (which I suppose can easily be handled by continuous 'Optimizing' of the HDD) you are saying that for DLing efficiency and speed ITSELF it is better NOT to pre-allocate then.  That is what I think I am understanding.  I almost always move the finished file(s) off the disc soon after completion anyway; so, I would THINK that the combination of doing that and optimizing the HDDs used would probably take care of whatever resulting fragmentation results, correct...?

Appreciate it!

[Switeck]

IF using standard hard drives, I'd highly recommend pre-allocating the space to begin with.
The starting delay should be much shorter than the download time unless your connection is a fiber optic line.

Defraging after downloading can be nasty if you don't -- possibly taking many hours.

I don't recommend downloading directly to a SSD, although SSDs are great to seed from.

[latheofheaven]

Okidoke, thank you!