Async disk IO

Feature requests not specific to either the Mac OS X or GTK+ versions of Transmission
Post Reply
lvella
Posts: 4
Joined: Thu Nov 18, 2010 2:51 am

Async disk IO

Post by 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
Posts: 220
Joined: Sun Jan 24, 2010 12:41 am

Re: Async disk IO

Post by 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
Posts: 441
Joined: Sat Jul 31, 2010 5:04 pm

Re: Async disk IO

Post by killemov »

lazybones wrote: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
Posts: 552
Joined: Sun Dec 13, 2009 10:44 pm

Re: Async disk IO

Post by blacke4dawn »

killemov wrote:
lazybones wrote: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
Posts: 220
Joined: Sun Jan 24, 2010 12:41 am

Re: Async disk IO

Post by lazybones »

blacke4dawn wrote:
killemov wrote:
lazybones wrote: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?
x190
Posts: 5094
Joined: Sun Nov 30, 2008 4:59 am

Re: Async disk IO

Post by x190 »

This is all trac ticket #1753 stuff.
lazybones
Posts: 220
Joined: Sun Jan 24, 2010 12:41 am

Re: Async disk IO

Post by 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
Transmission Developer
Posts: 2311
Joined: Sat May 26, 2007 3:39 pm
Location: Titania's Room

Re: Async disk IO

Post by 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
Posts: 220
Joined: Sun Jan 24, 2010 12:41 am

Re: Async disk IO

Post by 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.
Post Reply