Possible race condition with bt.compact_allocation

[Serbian]

Note: if this was a known issue in 1.7.7 that got fixed at or before 1.8.4 then disregard. If it wasn't, then it's most probably still there. Actual case was on 1.7.7 bld 1879

This one is rather hard to repro, unless you guys have well controlled stress boxes. You'd need s rather big torrent (say 15 GB), with enough seeds and peers to reach at least 400 MB/s, the more the better, (say max peer count set to 100 and actual no above 50) and and to run on a reasonably slow box but still fast enough to process incoming data (test box was P4 (no hyper-threading) at 2.8GHz, with 1.5 GB RAM). Basically if Chrome takes long time to open pages and IE8 looks choked while uTorrent is getting 800 MB/s that would be approx good stress conditions. Another technical condition: small number of big files (>500MB each), say package like LinuxCBT at isonut would be fine, if you go for files >400 GB.

With bt.compact_allocation = true (and pre-allocate files off). that single temp file that's used for all incoming files will just get garbled after 30-75% of the transfer done (depends on the luck :-). One interesting aspect is that uTorrent did allow skipping files and all data was still in one temp file, so maybe is wasn't exactly doing "compact allocation" but it was one temp file for all files picked. Issue wasn't present if going for a single file, or files <400 MB and had vary reduced probability with lower speeds and smaller number of peers - all pointing to a possible race condition. Also, only that one temp file got garbled, there was no visible affect on other torrents or the app itself.

[Switeck]

400 MB/sec is impossible with less than a 10 gbit/sec fiber optic line (or aggregate of lines).

Also, only a VERY fast/large RAID can handle such speeds.

[Ultima]

that single temp file that's used for all incoming files

Um... what temp file? µTorrent doesn't use any intermediary files to store data -- it writes exactly to the correct file on disk.

[Greg Hazel]

bt.compact_allocation does not guarantee that any file is correct until the entire torrent is downloaded. So, things will appear "garbled" until that point.

The way bt.compact_allocation works is to store pieces in the order it receives them, instead of storing them in the correct order from the beginning. This avoids generating say a mostly blank 4GB file if uTorrent gets the last piece of the file first.