Python Like Disk Management

[ARcanUSNUMquam]

This is probably far-fetched, but if the authors could find a way to download the pieces and place them in as far as you downloaded, that would be great. That probably seemed confusing. Here's a better description.

http://azureus.aelitis.com/wiki/index.php/ConfigFiles"]Currently, Azureus can employ 3 disk-allocation mechanisms:

* Pre-allocate: Reserves the entire space on the filesystem, but may actually be using a sparse file (reserved, but not truely allocated), depending on the file-system. This is the Azureus default, when neither Allocate-and-zero nor Incremental are enabled.

* Pre-allocate and zero: Like pre-allocate, but actually writes the entire file full of zeros, forcing the fs to allocate the entire space.

* Incremental: File size starts out as 0, then increases to x size when byte x is written: i.e. if the end piece of a torrent is downloaded first, then the entire file size will be used.

There are subtle nuances to the above, depending on the particular fs employed, which I will not get into.

The python clients employ a 4th method by default, which is a more-intelligent form of incremental than what Az currently uses: like incremental, file starts out 0-sized, but when piece x comes in, it's appended to the current file position, even if it doesnt truly belong there. As new pieces come in, they are appended and shuffled around as needed: the file size grows only by 1-piece-size for every new piece written, but the pieces are not necessarily/usually in final order. Azureus will eventually support this form of incremental, but it's a ways off.

ABC, a Python client, will do the 4th method. As pieces are downloaded, they are appended to the file, and when completed, simply shuffled around until in the correct order. So if you've downloaded 20 mb of a 2gig file, only 20 mb is taken up on the disk.

As I understand it, only Python clients can do this. Other clients at best can use the "Incremental" method. I notice that uTorrent uses the incremental method. For exmaple, say you've downloaded the last piece of a 2gig file, that will mean 2 gigs is taken up.

If the authors can make uTorrent use the 4th method, that would be best, especially for those who download huge sized torrents on a small disk. (I routinely get 4-10 gig torrents on a 60 gig hdd, and I'm trying to work on a 14 gig one. Not exactly the best combo. My average free space hovers around 1 gig, and I do multiple torrents a lot, since my connection can handle it.)

Currently, this is the only reason why I'm not switching from ABC to uTorrent.

[bkman]

I'm guessing that this will be a way off for utorrent also, but in the meantime you can just use the Sparse file option, if you don't mind the drawbacks. See here: http://forum.utorrent.com/viewtopic.php?t=925

[ARcanUSNUMquam]

I see no Sparse option, and from what I can tell, this seems like the Incremental method.

And I'm using WinXP Pro. What is this Sparse attribute you speak of?

[boo]

I see no Sparse option, and from what I can tell, this seems like the Incremental method.

And I'm using WinXP Pro. What is this Sparse attribute you speak of?

in the advanced options, its called diskio.sparse_files

[bkman]

Sparse files are a lot like the 4th method of file allocation, but done at the filesystem level. Basically it means that only the parts of a file filled with downloaded data will take up disk space, and the empty parts will not.

[ph0rn]

I like having it allocating the total needed disk space so I know there is enough for the download to finish.

[ARcanUSNUMquam]

BEAUTIFUL. GOOD BYE ABC!

[1c3d0g]

BEAUTIFUL. GOOD BYE ABC!

Yesss...EGGcellent!!! Soon we will have world domination... :twisted:

[ssjkakaroto]

i know it's not a priority right now but i think this feature would be a good thing for the long future

[Firon]

i know it's not a priority right now but i think this feature would be a good thing for the long future

read the thread, the feature's already there really: it's called sparse files.

[ssjkakaroto]

thx, i didn't realize they were the same in the end

[Firon]

Though, there is one catch to it: you can only use it on NTFS partitions. (which means Win2k/XP/2003 only)

[Xilon]

Which means it won't be Linux (/other platform) compatable in the long run since those systems use a different filesystem. Also the sparse file allocation matches teh first pre-allocation description in the quote, so this isn't _exactly_ the same as the "python" method.

Btw would the python method be characteristic of the python language? The way I understand it is that it's the python language that somehow does that, which means that for uTorrent to utilize it a C "replica" of that functionality would have to be developed.

[vurlix]

It has nothing to do with the python language.

Ludde might implement it sooner or later. It's not very important, though.