Async disk IO

[lvella]

I am currently running Transmission on a machine with very slow disk interface (USB 1.0). The remote interfaces gets very slow and unresponsive when there is a high number of concurrent downloads (consequently, a high number of IO), so, I suspect the disk write calls are blocking Transmission threads for too long and causing slowness. So, what about using the SO interface for asyncronous disk IO to account for slow disk machines?

[lazybones]

Not only that but the entire Web API becomes completely unresponsive for the daemon when complete torrents do a simple file move from the temp directory if you have that option enabled.

Lets say you have your download target on a slow NAS and you use the incomplete temp folder option with local storage... When a 4 gig torrent completes, Transmission daemon basically halts all together till the transfer from local temp to remote storage completes.. This can be minutes of no UI response etc. It is incredibly annoying when compared to other torrent applications.

[killemov]

Not only that but the entire Web API becomes completely unresponsive for the daemon when complete torrents do a simple file move from the temp directory if you have that option enabled.

Lets say you have your download target on a slow NAS and you use the incomplete temp folder option with local storage... When a 4 gig torrent completes, Transmission daemon basically halts all together till the transfer from local temp to remote storage completes.. This can be minutes of no UI response etc. It is incredibly annoying when compared to other torrent applications.

This problem can be solved now with a script that detaches from the main process, like my Unrar and cleanup script.

Code: Select all

{
...
} &

[blacke4dawn]

Not only that but the entire Web API becomes completely unresponsive for the daemon when complete torrents do a simple file move from the temp directory if you have that option enabled.

Lets say you have your download target on a slow NAS and you use the incomplete temp folder option with local storage... When a 4 gig torrent completes, Transmission daemon basically halts all together till the transfer from local temp to remote storage completes.. This can be minutes of no UI response etc. It is incredibly annoying when compared to other torrent applications.

This problem can be solved now with a script that detaches from the main process, like my Unrar and cleanup script.

Code: Select all

{
...
} &

I sure he is talking about the built-in temp directory usage, not the option to use a script when completed.

[lazybones]

Not only that but the entire Web API becomes completely unresponsive for the daemon when complete torrents do a simple file move from the temp directory if you have that option enabled.

Lets say you have your download target on a slow NAS and you use the incomplete temp folder option with local storage... When a 4 gig torrent completes, Transmission daemon basically halts all together till the transfer from local temp to remote storage completes.. This can be minutes of no UI response etc. It is incredibly annoying when compared to other torrent applications.

This problem can be solved now with a script that detaches from the main process, like my Unrar and cleanup script.

Code: Select all

{
...
} &

I sure he is talking about the built-in temp directory usage, not the option to use a script when completed.

Correct, I want to keep seeding for a long time after download completes but I am using the "incomplete-dir-enabled" function to run transmission on a PC and store the incomplete torrents on local disk, then move the complete torrent (and continue seeding) to my NAS where I typically use the complete torrent right away.

I do not see the complete HANG that is present in transmission with other torrent clients such as deluge (I have other issues with deluge). With some torrents I am grabbing being several gigs now this problem only increases.

Basically for any major IO operation transmission fails to respond to anything else. If Async IO is not going to happen, then maybe the UI / webui / API should be spun off in another thread so it at least can report back that the primary program is busy or something.

Or at the vary least the specific move operation that is part of the "incomplete-dir"function could be spun off as a separate item?

[lazybones]

And as per the ticket this has been a persistant issue that numerous users want fixed but it is very hard to fix because it is at the core of the app.

So 3 years later it persists and gets more noticeable as torrents get larger.

[Jordan]

Even though the Proper Fix for this is still in #1753, nightly users should see a lot fewer GUI freezes because of the fix in #5168.

https://trac.transmissionbt.com/ticket/5168

[lazybones]

Doesn't sound like it will help the webui or remote API for the daemon unless I am reading the comments wrong. Sounds like a GTK / OSX only improvements, which is still a good thing.