utorrent rapes HDD with 4 byte reads/4k writes

[boomman]

When you force utorrent to create a partfile, it reads in the index of the partfile in brain-dead 4 byte chunks. Those 4-byte chunks are indexes into the partfile.

There have been many other things we wanted to fix in the disk system, so we haven't gotten to this rater old problem yet. We'll fix this in 3.3, and may back-port it to 3.2.

Thank you.

[boomman]

Well that happens with all new torrents now and even after I deleted settings.dat to reset settings.

Why you do not apply caching to utorrent .dat file?

Upd. No, not with all new torrents, just with big ones.

[Firon]

Turn off diskio.use_partfile, or don't skip files.

[boomman]

Turn off diskio.use_partfile, or don't skip files.

Thanks, first workaround helped. However, now files that I download take thrice more space than before due to preallocation of partially downloaded files.

Please let me know if you acknowledge that this is a bug and should be fixed. It shouldn't be hard, just apply cache to those operations.

[Firon]

It is a bug, and it has nothing to do with caching. We just have a bug where we write way, way more to the partfile than we're supposed to (almost infinitely), so it will take hours to finish "flushing".

[boomman]

Firon,

Any ETA on this partfile bug? Do you know the cause? It really annoys me, I cannot download any large torrents

[Firon]

As far as I can tell, this is no longer a problem on 3.2.

[rafi]

As far as I can tell, this is no longer a problem on 3.2.

You sure? On what build was it tested ?

[Firon]

I haven't been able to repro this in over a month honestly with any recent build of 3.2. I haven't seen any other reports about the issue either (they used to be fairly widespread).

[AdamK]

Whoops. Sorry, boomman. I put my answer in your first post. We'll update this thread when we have it fixed.

[rafi]

There have been many other things we wanted to fix in the disk system, so we haven't gotten to this rater old problem yet. We'll fix this in 3.3, and may back-port it to 3.2

Thanks for the updated status

I haven't seen any other reports about the issue either (they used to be fairly widespread).

I'll make sure to send you a copy of my test report ... I think those 100 people running this beta are just getting tired of reporting issues that the ETA for a possible fix is far far away ... Issues usually do not tend to magically disappear ...

[boomman]

I still see this on 3.2.1.

http://i.imgur.com/P7bil.jpg

I am supposed to get ~4 MBps, instead I get less than 150 kbps and HDD writes with 32 MBps speed.

[MrStanky]

I haven't been able to repro this in over a month honestly with any recent build of 3.2. I haven't seen any other reports about the issue either (they used to be fairly widespread).

I'm getting this an awful lot on 3.2 build 27886

With 2 torrents going at once, there doesnt seem to be an issue. If I force start a 3rd torrent, within approx 1 minute uTorrent begins sending 4MB/s (while only receiving about 1MB/s). I dont know what is in the data or where it is destined for but it doesnt look like its written to my NAS where my torrents are saved to. As my WiFi connection's bandwidth (130MB 802.11n) is now getting hammered on, reading/writing to my NAS is delayed, causing a 'Disk Overload'

I can stop the Force Started torrent, but the 4MB/s continues until I exit the program. uTorrent remains resident in memory for about 2 minutes until it finally closes. The instant it closes, the 4MB/s disappears.

If you guys need more info or need to recreate it, let me know. I just wanted to let you know this is still an issue.

EDIT: The 4MB/s is reported through Microsoft's Wireless Network Connection status. uTorrent only says it is sending 10KB/s. I have been able to recreate this the last 5 times I've tried so I know the 4MB/s is uTorrent related.

[rafi]

-- 2012-08-08: Version 3.2.1 Beta 2 (build 27718)

- Fix: don't write the block list in a part file in 4-byte increments

Maybe a regression of that fix? Please show a process explorer log of the write operations.

[turtulla]

As far as I can tell, this is no longer a problem on 3.2.

Looks like it is still a problem. I'm currently using uTorrent 3.2.2.28595 (but the same behaviour existed in all previous versions) and here is uTorrent's file activity shown by Process Monitor:

http://i47.tinypic.com/29z76di.jpg

As we see, some torrent's part file is being read by tiny 4-byte pieces. This part file is about 50 MB big, the torrent's total size is about 400 GB out of which only 24 MB have been downloaded, the torrent's piece size is 16 MB, total number of torrents being seeded simultaneously is 700+. I re-downloaded the torrent to test for the possibility that the part file format is different in uTorrent 3.2.2, but the problem didn't go away (although the part file's contents has changed with the size remaining the same).

This kind of behaviour is not constant, but appears periodically when the torrents with big part files are seeded. It consumes CPU power uselessly and interferes with other uTorrent activities on slow computers which may produce a wavelike (fluctuating, undulating) upload pattern:

http://i48.tinypic.com/2pr8itd.png

Since part files may reach gigabytes in size on really huge torrents, this uTorrent issue is becoming quite annoying, therefore I think it must be addressed in the nearest release.