Does Transmission Fully Preallocate Files?

[bitburner]

I was wondering if transmission fully preallocates disk space for files? Thanks in advance!

[kjstart1]

excuse me, I am using Optware IPKG version Transmission 1.92 and running it on ext3 partition, all downloaded files take very long time to read from disk. I guess this is caused by transmission does not allocate disk space at download beginning and make lots of disk frags. To prove it, I copy a duplication for my downloaded file in same partition, this duplication has 3-5 times read speed than original file in my test. At last, thanks for develop so good software, it is very easy to use, specially for the web UI.

[kjstart1]

"preallocation": 1,

I will try to find other reason, thanks any way.

[Rolcol]

Preallocation should be set to 2 if you want the file to be created completely in one go. Some filesystems allow the file to be preallocated without writing zeros to it first. HFS+ on OSX and several different Linux filesystems (ext4 comes to mind) support it.

[kjstart1]

Thanks you guys, I will try it later.

[carharot]

It doesn't work.
closed one.
Add preallocation = 2 into ~/Library/Preferences/org.m0k.transmission.plist and save.
run one
add 50 GB torrent. after a few minutes I pause torrent and watch how running disk i/o in ~100 MBps about 20 min. app was running to write zeros.

apple hfs+ can't create whole files as ext4/ntfs/sgi xfs.

[carharot]

Read that ticket but can't understand "what must I doing that decide that problem".

Under Linux (ext4) ktorrent (as example) is working good. doesn't write zeros when create full files. uTorrent (windows/ntfs) works fine as well.

[carharot]

2 x190

Excuse me, but can you tell me what's message number (about #1753 one) that give advice about "worker threads" setup.

I can wait when a some torrent will have complete operation, but in that moment I can't have a normal access to download partition/to transmission. all're freezed about ~10, 20, 30 minutes.

I recur to old my message: ktorrent (my Linux gentoo/ext4), uTorrent (windows/ntfs) doesn't have a such problems "from 90x".

I was putting up with it in last 90x years and 2000, 2001 years. Now the modern clients and file systems can create files with any size without zero filling "feature", and (that's naturally) without fragmentation.

at all events ext4/zfs/xfs/btrfs and any modern clients under Linux can it.

What's under OS X/hfs+ with transmission.

that hfs+ "feature" just is fake? fabrication?

who is "author" of that moment ?

[cfpp2p]

Excuse me, but can you tell me what's message number (about #1753 one) that give advice about "worker threads" setup.

You can't 'setup' worker threads as a user. You'll have to patch the source code and recompile. Figuratively, the needle will have to be unthreaded first, the re-threading of the needle is really difficult. So far no one has been able to achieve this 'patch' for transmission.

[carharot]

As I understood that macports haven't such pitched one, have it?

let that one will be as cli one. not gui. no problem.

Just I don't know - what's a normal torrent client under OS X. accustom to quality system. ktorrent/linux. Even transmission under Linux works better than under Apple OS X. Used it under gentoo. On the OS X use web client for transmission engine that was under nix.
There is all ok with file creating without zero fill. ext4/transmission.

not but OS X is closed proprietary system and you can't change normal app for it. understood.

OS X hold because of quicktime 7.6. There are not qtime with qtkit/perian etc codecs. a powerful one. and fcp x. only because of that couple.
what a shame...