I'm using transmission (1.51 currently) at my NAS - Dlink DNS-323
I've recently found that all downloaded content comes nasty fragmented For instance I've never been able to copy any new file to PC at rates faster than 3-4 mbps. But when it is copied and dumped back to NAS inplace of old file coping speed (both up and down) become excellent (up to 30 mbps)
Coping files to new location is not very quick and convinient solution. vast majority of my files are quite large - 4-40 Gb. But AFAIK there are no any relevant utilities for defragmenting ext2 (I heard they only going to introduce something of that kind in ext4)
Is it possible to do something from transmission side ? Teach it to write pieces/blocks not by linear way but exactly to places where they should be in the final file. and avoid fragmentation entirely.
Superb ! That's exactly what I want Now turn it on. will try and test ! Preallocation : 2 - definitely better choice for me.
I would even suggest to make it default instead of 1. There are no detailed description for configuration parameters or guides for tuning.
so many of newbs (one was me) not even guess what is the root case of poor transfer rate and twitching of movies on theirs mediatanks ... they messing with NFS, medaistreaming and so on.
Well as far as solution already exists we probably can close the topic. Transmission is excellent and powerful client. Thanks for your great work !
I have tested preallocation:2
This definitely makes things better without any noticable drawbacks but fragmentation still retain.
coping rate of downloaded files is now 6.5 mbps instead of 8.5 for non fragmented content via 100 mb network
and only 9-10 mb with gigabit vs 30 mbps for non fragmented ....
I think fragmentation problem still makes a big point for future improvement of new data blocks allocation algorithm ....
I'm using T 1.51 on Popcorn Hour 110 NMT, ext3 filesystem, preallocation is set to 2. However, downloaded video files are still terribly fragmented, so that they are unwatchable (playback constantly stutters). It is definitely fragmentation, because after copying (not moving!) file elsewhere on the same disk it is played seamlessly. This issue is very common in our local PCH community, everyone using T suffer it. Maybe there should be some "forced" preallocation, which would fill every chunk with zeroes before downloading it (having file in 1-4 MB fragments is way better than in 4KB, and filling the whole file takes way TOO long, especially on such weak hardware). Thanks!
Do something to fix the problem pleeeeease .... All our local DNS-323+transmission community terribly suffer from it
preallocation:2 doesn't much help. On the other hand native torrent client for DNS-323 downloads without any fragmentation ! So it is possible ! But native client is very simple and has other disadvantages and I get used to transmission and it is good and best in all other respects.
Well if it's really hard to do someting with engine and preallocation algoritm what about implementing very simple solution like this:
optionally download to temporary folder and when finished copy content to final location for seeding ?
I've got this exact same problem on my NAS, the Readynas NV+ from Netgear (Infrant).
I get terrible fragmentation on content downloaded by Transmission 1.52 running on this device and by that poor performance copying/streaming it afterward.
Copying content once locally gives me low fragmentation and the expected performance again; like other users report.
For me the preallocation-setting do nothing, 0,1 or 2 makes no difference whatsoever.
Is this a known issue? Or a filesystem problem with ext2/ext3? (I saw a bug regarding XFS about similar matter)
wishyou wrote:I've got this exact same problem on my NAS, the Readynas NV+ from Netgear (Infrant).
I get terrible fragmentation on content downloaded by Transmission 1.52 running on this device and by that poor performance copying/streaming it afterward.
Copying content once locally gives me low fragmentation and the expected performance again; like other users report.
For me the preallocation-setting do nothing, 0,1 or 2 makes no difference whatsoever.
Is this a known issue? Or a filesystem problem with ext2/ext3? (I saw a bug regarding XFS about similar matter)
Wish
What's the proper OS call to make to preallocate a file on that system?
Also, could you post the section of config.log where Transmission is looking for fallocate(), posix_fallocate(), etc?
This is a debian-sarge distro built for a sparc-processor.
I do not know what the proper preallocate call is, but from super-poussins config log it looks like the system supports posix-fallocate()
For the record, the files downloaded actually look complete in size after a short while, but extents reported from filefrag increases steadily as the download proceeds.
Any news on this one? I think it's obvious that on NMT (and perhaps other platforms like NAS) posix_fallocate doesn't actually allocates clusters - just reserves the disk space for future. So the only way I see is filling the chunk with 0's before starting downloading it (at preallocation=2, of course, or maybe even 3). This will slow down download, but is way much better than filling the whole file at the beginning (this would lead to HUGE delays on weak platforms).
If someone on the NMT cooks up a clean patch for this I'd very likely use it. I think that would waste a lot less time than me trying to write code that optimizes for a system I can't test on. (hmm... maybe if NMT were to send me a sample box...
I've took a quick look through T sources, and the first (and probably wrong ) place to put the patch on is at the end of tr_peerMsgsAddRequest function in libtransmission/peer-msgs.c file. The patch itself looks like this:
Of course, this is extremely draft version, but I'd like the T developers to comment, is this actually a place where we begin downloading a new chunk? If so (and the function tr_ioWrite actually writes data to the disk considering it can span over different files), I think I'll find a way to build this special version of T and test it on our hardware.