Idea: option to do torrent verification in background manner.

[User294]

Right now sometimes the following issue could arise:

User may want to use some machine with slow disk subsystem. As typical example, notebook with single slow 2.5" HDD running T could be a good example. In this scenario, full-speed torrent verification may cause whole OS to become unresponsive as other tasks have to share bandwidth of completely busy disk with T. If torrent(s) are large, this could lead to unresponsive system for a while.

While I personally believe that in the ideal world it's a good job for OS built-in I/O scheduler to keep system responsive in such scenario, it looks like in real world, some OS+hardware combinations could be far from perfect in this regard (most notably, some BSD users admitted this issue). So users sometimes complain that torrent verification renders their OS unresponsive.

Idea is: maybe there could be option to limit such I/O to relatively slow speed (like 5Mb/sec, but it should be configurable I guess) so torrents are verified completely in background, without slowing down system too much, even if system is not perfect and disks are slow? Ideally, such limits should also apply to full preallocation and data moving as well if user desired to have a "completely background" activity, even at the cost of operations speed.

While T behaves OK in my configurations, I still see a point in such complaints. User may want to have a good desktop experience even if T is running, no matter what operation is in progress and how crappy their OS+disk subsystem behaviour is under heavy loads.

[jordan]

There's already a ticket open for moving preallocation and data moving to a worker thread.

When you click on "verify local data" that already happens in a background worker thread.

About adding in I/O limitation during verify s.t. the background thread doesn't affect foreground work... it's a balancing act. Transmission currently adds small sleep calls after verifying every piece during "verify local data" for just that reason, and it seems to work well in practice. But there have also been people who have complained about those sleep calls and feel that the scheduling should be left to the OS.

And about the "good desktop experience" ... if heavy p2p activity is slowing down the desktop because of disk I/O, then people seeing that should reduce their speed limits. Having Transmission automatically apply a throttle would just trade one problem for another one, and the people complaining about disk I/O would be traded for people complaining about slow speeds.

[User294]

then people seeing that should reduce their speed limits

The problem starts here: you can't reduce speed of torrent verification - it has nothing to do with network speed limits and seems to be performed as fast as possible, causing a decent disk I/O utilization up to being limited by HDD speed (good job, btw :D).

Imagine that you have 30 * 20Gb torrents to re-check for some reason. It will take ages to verify them anyway. In such cases it could be desirable to reduce verification speed to allow normal system usage as if there was no T running at all, but still slowly re-check torrents queued for verification "completely in background" - without causing too much strain on HDD, so it can quickly serve requests of OS and other apps, therefore improving overall user experience at this time. So user would be able, say, watch movie from the same slow HDD without frame drops while T slowly verifies data in "stealth" way.

Btw, small sleep calls itself or low priority of thread does not warrants that IO would not become saturated and that speed of IO operations would not degrade for system as a whole.

and the people complaining about disk I/O would be traded for people complaining about slow speeds.

Sure! I can see this problem as well. That's why I think it should look like this:
[X] limit move/verify/preallocation to N Mb/sec.

Those who favors speed over system load should not use this, ever. Those who want low system load more than verification speed can use this to limit impact on other disk operations.

You can also try hinting OSes that these are bulk low-priority disk ops and let OS to cope with it itself, preferring other IO ops if possible, but AFAIK APIs are different across OSes for doing this and not each and every OS haves idea on what the hell I/O priority is and I'm not sure this could and would work well enough. Just doing some extra (adjustable!!!) sleeps to reduce disk I/O on verification/move/preallocate (if desired by user!) probably a better idea. However, those do not have to be small sleeps but rather they have sleep as much as it needed to reduce IO to certain level like "verify should not exceed 5Mb per second when reading" (to keep disk free for other requests).

[livings124]

There doesn't seem to be a solution to this that makes everyone happy. As jordan noted, there is a ticket for doing this in a thread. In the meantime, I believe we have hit the balance between speed and io..