the forums at degreez.net

I was just wondering how the different disk allocation types (normal, pre-allocate, background, sparse) do.

I understand that 'normal' mode allocates diskspace as the data arrives.

'Pre-allocate' mode allocates diskspace for the whole download at the start.

'Background' does the same thing as 'pre-allocate', except that it allocates the diskspace slowly depending on the allocation rate throughout the download. It reduces disk thrashing.

I don't know anything about 'sparse' mode. I'm completely lost as in to what it does. Could somebody explain how it works?

The other thing is, I assume that 'normal' mode causes more disk defragmentation than 'pre-allocate', or 'background'?

Thanks in advance

"Sparse" is for use on some filesystems, notably many that work under Unix, which can create a "virtual" file filled with zeros until those parts of the file are written into. This has the advantage of not needing disk space until it's actually required and not needing to move data as space is allocated. It has the disadvantage of creating extreme fragmentation in the files. This method does not work under Windows 2K/XP even though NTFS supports sparse allocation because it isn't supported by default and I have no way of turning it on.

I see, so better not use sparse file allocation mode right? got it thx

What do you mean by doesn't work on 2k/XP? I had Azureus a while back, and some version of it use Sparse. It worked fine. But it don't like it because of, as Shad0w said, the very high fragmentation rate.

They're based on Java, not Python, and they may have access to more Windows services than I do. Or they may just be labeling it "sparse" and leaving it at that. My client works under "sparse" mode with Windows, though it's not really sparse it can cause some problems with high CPU/disk access when the client is shut down or when transfer rates are high early in the torrent.

You can set a file sparse under NTFS with the command line:


Another command might work well for file allocation:


I was able to create a 170mb file instantly with this command. Using my defragger to check, this file was in 2 fragments, same as the file manually allocated and zeroed out by BitTornado.

Hopefully these can be used to improve BitTornado on Windows