write cache is full

[Guest Reetm]

Why BT can't write files to disk? I know they're big like 1 GB and downloading speed is fast, 4-7 MB per sec. but why it's taking sooo long?

By long I mean I made this screenshot, uploaded image, found this forum and made this post while BT still writing cache to disk. Or maybe Comodo antivirus involved?

[Harold Feit]

What specific version are you using? (Help -> about)

[Guest Reetm]

What specific version are you using? (Help -> about)

7.6.1 (27208) 32 bit

After exit and restart, downloading continued normally, but only part of the cache was written, 3/4 lost.

[hydroknight01]

I also experience this problem when downloading several torrents. I've found a work-around of sorts, but I would like to see a more permanent solution.

Generally, I find that adding a maximum rate to your upload and download speeds tends to help; I tend to set my max DL to 250kb/s and vary it up or down as needed; I then set the max upload to 50kb/s when downloading, then alternate to unlimited when all torrents are done downloading.

I also find that setting the queueing to only one torrent downloading at any one time, and only four torrents active, including seeds, at any one time, tends to help too. This does mean that things take much longer to get done, but it helps to keep the cache from filling up.

Please note that your computer and storage device undoubtedly have different download speeds and cache sizes to my computer system; you might have to experiment a bit, and do some micro-managing, in order to make this work for you.

I hope this helps somewhat, at least until a more permanent solution is found.

[ARRC]

I've been using BT for years and have the current version 7.6.1 installed. Never had any problems in the past.

However, having the same problem as above with the cache writing getting stuck. It seems to be localized to a torrent using 4MB piece sizing. Other torrents that I have shared recently worked fine. The cache is set to auto at 32MB. I'll usually get about 20MB of the cache written out to disk before the writing to disk stops and the writing to cache starts loading up and approaches the 32MB limit. At that point I get the 100% full notice on the status bar and the dl and ul rates drop to a couple of kB's each. But the cache never flushes to disk. I keep watching the pieces fill up to 256 blocks out of 256, but they just stay in the queue. Normally they immediately flush to disk and the pieces are counted as completed. That doesn't happen. If I change the cache size to allow the file to complete downloading, all the pieces remain in the pieces queue showing 256 out of 256 but they never flush to disk.

The only thing that seems to work is to wait for the first 5 pieces to flush to disk, then stop the torrent. Exit BT and restarting BT will start the torrent loading again with a clean cache. The problem with this solution is that it takes forever to download a torrent.

Any ideas that might be a better solution. This only seems to happen with torrents that have a 4MB piece size (256 blocks per piece). Is this a bug?

PS. I solved the problem by removing BT 7.6.1 and installing BT 7.5. The cache is now working properly and the torrents DL and UL fine.

[Guest Guest]

I've been using BT for years and have the current version 7.6.1 installed. Never had any problems in the past.

However, having the same problem as above with the cache writing getting stuck. It seems to be localized to a torrent using 4MB piece sizing. Other torrents that I have shared recently worked fine. The cache is set to auto at 32MB. I'll usually get about 20MB of the cache written out to disk before the writing to disk stops and the writing to cache starts loading up and approaches the 32MB limit. At that point I get the 100% full notice on the status bar and the dl and ul rates drop to a couple of kB's each. But the cache never flushes to disk. I keep watching the pieces fill up to 256 blocks out of 256, but they just stay in the queue. Normally they immediately flush to disk and the pieces are counted as completed. That doesn't happen. If I change the cache size to allow the file to complete downloading, all the pieces remain in the pieces queue showing 256 out of 256 but they never flush to disk.

The only thing that seems to work is to wait for the first 5 pieces to flush to disk, then stop the torrent. Exit BT and restarting BT will start the torrent loading again with a clean cache. The problem with this solution is that it takes forever to download a torrent.

Any ideas that might be a better solution. This only seems to happen with torrents that have a 4MB piece size (256 blocks per piece). Is this a bug?

PS. I solved the problem by removing BT 7.6.1 and installing BT 7.5. The cache is now working properly and the torrents DL and UL fine.

It's not just the 4MB blocks, although I have seen the problem occur frequently (almost consistently) with the large blocks; they just sit in the cache and since they're large, the cache fills up. However, I've also seen the problem occur with small blocks (64Kb); if you use the "Pieces" tab, you'll see one block after another fill and the number of pieces in queue wll just add up. In one case, with one seeder and no peers, with only a slow download speed, I had over thirty blocks in queue (per the "Pieces" tab) waiting to be written.

As others have indicated, stopping and restarting BitTorrent seems to be the only solution at the moment. Initially, there are disk writes from cache, but then they just stop. Period. The application never recovrs.

I've been running tests on this for several weeks now, trying to find any trend. I've played with all the parameters in the Preferences Advance Disck Cache settings and played with bandwidth allocation. The only thing that "works" (sarcasm intended) is to limit myself to one download at a time with a slow download speed.

7.6.1 is broken; this problem didn't exist previously.

Just guessing, this is a multi-threaded application (only way to code it sensibly) and there's some kind of race condition causing a lock-up. Nothing we can do to really work around it on our end.