transmission hangs everytime i add a torrent

On Sat, 2010-03-13 at 23:08 +0000, Rus F Adrian wrote:
> Public bug reported:
> Everytime I add a torrent, transmission freeze, i have to force quit to
> close transmission.I added a backtrace dont know it is useful.
Thanks for your report. what partition type is partition mounted
in /media/sda2/?
 status incomplete

The question was of course about filesystem present on a partition mounted to /media/sda2 and not about partition type. Sorry.

The partition mount in /media/sda2/
  Device Boot Start End Blocks Id System
 /dev/sda2 3886 27719 191446605 7 HPFS/NTFS

* cat /etc/fstab

UUID=01C9DB3DA127D500 /media/sda2 ntfs-3g defaults,locale=en_US.utf8 00

Yes it is about the partition mount in /media/sda2.I change the save location to my root partition and it didnt hangs.It their a problem with my partiton?How do I fixed it if you know? Thanks for the reply.

The freeze is being caused by slow file preallocation. You can ameliorate this by using a faster filesystem, or faster media, or by turning off preallocation.

If the filesystem doesn't support a fast allocation call like fallocate64(), and preallocation is set to "full", then preallocation is unavoidably going to be slow.

Thanks charles for make me understand, I try to migrate from ntfs to ext4.

That's not an answer! I was using Transmission flawlessly for many months with 0904 and 0910, writing to a remote file share. Immediately that I moved to the 1004 beta this started happening.

It was fine before. With 1004 it is not. There is a genuine issue.

Actually I think you're right.

The problem seems to have been introduced in r10075, where we make the default `full' allocation if fallocate64() is present on the system. The previous default was `fast'. r10075 was a bad idea, since *having* fallocate64() on your system is no guarantee that fallocate64() will actually succeed for your filesystem when it's invoked, and if it fails, things will still be slow.

r10337 fixes this in a way that fails more gracefully. since 1.92 is based off r10363 it has both of these patches, so fixing this for 10.04 is a simple/safe fix of backing out r10075 s.t. we always use `fast' as the default instead of doing an #ifdef HAVE_FALLOCATE64 ... `full' #else ... `fast' #endif

Here is the patch to back out r10075: http://trac.transmissionbt.com/changeset/10463

This isn't a showstopper for 10.04, but IMO it would be good to have and is a safe, unambiguous fix.

That last comment was a bit tangled. Here's a translation into English:

The original problem (bug #445592) was addressed upstream in two commits -- r10075 and r10037. The first commit causes this ticket's problem, and the second commit makes the first one moot. So, this ticket can be fixed by backing out r10075. This has already been done upstream: http://trac.transmissionbt.com/changeset/10463.

This is a nice-to-have for 10.04. The diff is about as simple as they come.

This bug was fixed in the package transmission - 1.92-0ubuntu2

---------------
transmission (1.92-0ubuntu2) lucid; urgency=low

  * Default to the fast preallocation mode. (LP: #538580)
 -- Krzysztof Klimonda <email address hidden> Wed, 14 Apr 2010 01:14:17 +0200

sorry but no fix here, same behave hangs when i save the torrent to a ntfs partition.

Architecture: i386
Source: transmission
Version: 1.92-0ubuntu2

Right, the change is only for new users. The existing lucid users have preallocation set to full and we can't change it automatically.
Can you shut down Transmission and edit ~/.config/transmission/settings.jsoc - change "preallocation": 2 for "preallocation" :1

Krzysztof Klimonda, I change from ~/.config/transmission/settings.json from "preallocation : 2" to "preallocation : 1" and is working.Thanks.

I believe I am experiencing the same problem.

It seemingly only occurs when I attempt to add more than 3 torrents to the list.

My settings.json file already had "preallocation : 1"

Version: 1.92-0ubuntu2.1