Opened 9 years ago

Closed 7 years ago

#849 closed Enhancement (fixed)

preallocation to prevent fragmentation

Reported by: aleehk82 Owned by: charles
Priority: Normal Milestone: 1.40
Component: libtransmission Version: 1.73
Severity: Normal Keywords: patch, preallocation, fragmentation
Cc: ashalimov@…

Description

Ubuntu 8.04. ext3. Files become heavily fragmented since I download several simultaneously. It's nothing critical but filesystem performance will degrade with time.

Attachments (4)

preallocate.diff (24.5 KB) - added by charles 8 years ago.
updated patch
preallocate-nopref.diff (6.5 KB) - added by charles 8 years ago.
revision of the patch w/o a preferences option
preallocate-nopref.2.diff (7.9 KB) - added by charles 8 years ago.
1.diff (2.4 KB) - added by hdfan2 8 years ago.
complete patch for file zero-padding with some additional error handling

Download all attachments as: .zip

Change History (50)

comment:1 Changed 9 years ago by aleehk82

  • Component changed from Transmission to libtransmission
  • Owner set to charles
  • Severity changed from Normal to Major

comment:2 Changed 9 years ago by charles

  • Severity changed from Major to Normal

found on the Ubuntu forums:

The default Ubuntu filesystem ("ext3") will fragment large (>1GB), slowly-growing files (<1MB/s) . Such files include torrents or huge downloads. You may notice it when trying to burn the files onto a DVD, when the burn process has to slow down because it cannot read the file fast enough to keep up. However, the rest of your system will not be affected by these fragmented files (for example, Openoffice won't start slower because you have a fragmented DVD ISO on the drive).

For the most part, this is not enough to bother people, but if you are a heavy torrenter/downloader, it could be enough to bug you. If that's the case, you can first try turning on your torrenting program's "preallocation" feature, which quickly creates an empty file the size of your torrent. This will cut down greatly on fragmentation. If that's not enough, you may want to consider using a different filesystem. XFS is the king of performance in this regards, but because of its aggressiveness you'd want to make sure you don't suffer from too many improper shutdowns/resets.

comment:3 Changed 9 years ago by charles

  • Summary changed from transmission needs good preallocation to prevent fragmentation on ext3 filesystems to preallocation to prevent fragmentation

comment:4 Changed 9 years ago by wicktransmission

  • Version changed from 1.11 to 1.21

I wanted to add this ticket for a completely different reason. When downloading with limited disk space, it is nice to have good data on whether or not you have room for another large download. If you have a few large downloads in progress, it is not clear currently whether or not a nearly-full disk will accommodate one more large download. With preallocation, the OS tells you how much disk you have left and there is no ambiguity.

comment:5 Changed 8 years ago by charles

  • Status changed from new to assigned

comment:6 Changed 8 years ago by Lam

I'd like to propose this option to be named "Fragmentation prevention" and have three states:

  • None (default),
  • Preallocate space when adding a torrent,
  • Defragment files after torrent completes.

Third option would have some advantages:

  1. Downloading would start right away, instead of waiting for filling the disk with possibly many gigabytes of zeroes.
  2. When downloading lots of gigabytes (like DVD ISOs) in parallel from slow sources/on slow link this would spare lots of disk space (assuming we're burning and freeing the space whenever one of them is finished, this would allow for more downloads at a time).
  3. When adding many big torrents at once, preallocating them all would be done in the same time (imagine the disk thrashing and time before any download starts). But they are unlikely to finish at once, so the defragmentation afterwards looks like better resource use.
  4. If we start some download and then decide we won't need that (after examining list of files or seeing low speed), we don't waste time nor space.
  5. If we start a download and then exclude some files (prevent them from being downloaded), we don't waste time nor space.

The only disadvantage I can see would be the space needed to make another copy of possibly many-gigabyte file on the disk after it completes. This is not a problem if only someone implements a new state for the torrent (completed, waiting for defragmentation).

Comments and code welcome :)

comment:7 Changed 8 years ago by charles

I see your point, and it's not a bad one, but feel that the complexity of three choices here outweighs the advantages of the features.

I also really don't like the idea of temporarily requiring 2x the disk space. The error handling and recovery in that sounds like a big headache. :)

comment:8 Changed 8 years ago by add

by end users who would like to contribute and start to use docs to learn cool stuff about their apps in the first place. Both annotations and contributions will only clutter the interface by default as a design pattern rather than trying to put it all together. That way you can never create offline or print docs of high quality without again having the devs or current admins maintain the comments and annotations. Hopefully a small Wiki quality team will evolve (i am against ops or admins) to review and summarize the contributions. I hope this gives us more users as contributors than having the docs focused on the devs. Cheers, duns china tour Apparel shoes bags Kitchen Food and Wine Furniture) Flowers and Gifts Wall Art Computer Components I still prefer a wiki like approach since the php (or mysql) docs are very cluttered when you have to take their comments in account. On the other hand they are professionally maintained imho, since they are *much* better than KDE documentation. KDE is by far larger and has so many different apps, which need screenshots and end user not dev/api docs

comment:9 Changed 8 years ago by sandeen

I'd suggest simply using posix_fallocate(). On recent glibc and recent kernels, if the underlying filesystem supports the sys_fallocate call(), it will quickly preallocate the space, and it will be largely contiguous. xfs, ext4, and ocfs2 all support this today. If the filesystem or kernel doesn't support sys_fallocate, then glibc will just write zeros to preallocate the space.

There is also an xfs-specific ioctl to quickly preallocate space, but in the interest of simplicity for the calling application, posix_fallocate() might be best going forward. The fall-back-to-writing-zeros case might be slow, so you may still want it to be configurable.

comment:10 Changed 8 years ago by charles

I'd never heard of that, but on the surface it sounds like a good idea. Thanks for the suggestion.

comment:11 Changed 8 years ago by sandeen

Just FWIW, the posix_fallocate interface is described here:

http://www.opengroup.org/onlinepubs/009695399/functions/posix_fallocate.html

Some early info on the sys_fallocate syscall:

http://lwn.net/Articles/226436/

It was initially merged in 2.6.23

I'm not exactly sure when glibc got wired up, and having trouble finding it in changelogs. Recent Fedora has it, I know.

comment:12 Changed 8 years ago by charles

sandeen: is this portable to Darwin too?

comment:13 Changed 8 years ago by sandeen

I'm not certain about Darwin... I'll see what I can find out.

comment:14 Changed 8 years ago by charles

As an aside, this conversation about the same topic is somewhat informative...

comment:16 Changed 8 years ago by charles

  • Milestone changed from None Set to 1.50

comment:17 Changed 8 years ago by charles

  • Keywords patch added

Changed 8 years ago by charles

updated patch

Changed 8 years ago by charles

revision of the patch w/o a preferences option

Changed 8 years ago by charles

comment:18 Changed 8 years ago by charles

  • Milestone changed from 1.50 to 1.40

provisionally committing this to the nightlies in r7051

comment:19 Changed 8 years ago by charles

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:20 Changed 8 years ago by hdfan2

  • Cc ashalimov@… added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Unfortunately, the problem is still present on some embedded platforms (NMT players and some NAS'es). Setting preallocation flag to 2 doesn't help - 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. Looks like on those platforms posix_fallocate doesn't actually allocated disk space, just reserves it. This issue is very common in our local NMT community, everyone using T suffers it a lot. The solution is obvious - add another option (something like preallocation=3) to pad all files with zeroes before downloading. This will slow down beginning of download, but will simplify life for a lot of people. The appropriate patch is extremely simple, something like that:

if( preallocationMode == TR_PREALLOCATE_FILL )
{
    uint8_t buf[ 4 * 1024 ];
    memset( buf, 0, sizeof( buf ) );
    while ( length > 0 )
    {
        const size_t thisPass = MIN( length, sizeof( buf ) );
        write( fd, buf, thisPass );
        length -= thisPass;
    }
}

which should be located in preallocateFileFull function in libtransmission/fdlimit.c after successfully opening the file (and, of course, declaring constant TR_PREALLOCATE_FILL in transmission.h; sorry for not providing complete diff). Please consider including this feature into Transmission. Thanks!

comment:21 Changed 8 years ago by charles

hdfan2: just to make sure I'm understanding the previous comment right: you've tested this out on the NMT and confirmed that it fixes the preallocation issue there?

comment:22 Changed 8 years ago by sandeen

posix_fallocate should -always- either write 0s or do the smart preallocation with uninitialized blocks as far as I know. The latter depends on both glibc & filesystem support. But AFAIK posix_fallocate will always at least do exactly the zero fill you're talking about. Can you try this on the box in question?

#define _XOPEN_SOURCE 600
#include <stdlib.h>
#include <fcntl.h>
#include <string.h>
#include <stdio.h>

void main(void)
{
	int fd, ret;
	
	fd = open("mytestfile", O_CREAT|O_RDWR, S_IRWXU);
	if (fd < 0) {
		perror("file open failed");
		exit(1);
	}
	ret = posix_fallocate(fd, 0, 16777216);
	if (ret) {
		printf("posix_fallocate failed: %s", strerror(ret));
		close(fd);
		exit(1);
	}
	close(fd);
}

and see what the resulting "mytestfile" looks like?

Or, can you check the actual fragmentation of your file somehow? (the "filefrag" util from e2fsprogs should work on any generic filesystem)

comment:23 Changed 8 years ago by Ger Teunis

hdfan2's change can be tested with CSI and this download http://download.nmtinstaller.com/transmission-1.61-nmt-fac-test.zip

comment:24 follow-up: Changed 8 years ago by hdfan2

charles: No, I didn't try this yet. I hoped to do this yesterday (with the help of Ger Teunis), but we've run into some problems. Hope today they will be resolved, and I'll test it ASAP. Probably I've reopened this issue too early (sorry), but the problem is definitely there, a lot of people suffering it, and the sooner it'll be defeated the better.

sandeen: The description of posix_fallocate says: "The function posix_fallocate() ensures that disk space is allocated for the file referred to by the descriptor fd for the bytes in the range starting at offset and continuing for len bytes. After a successful call to posix_fallocate(), subsequent writes to bytes in the specified range are guaranteed not to fail because of lack of disk space." Looks like on weak platforms (NMT, NAS'es) they decided to go with sparse files (to fulfil the last condition) to speed this function up. Anyway, right now I (and a lot of other people in our community) see several things (with preallocation=2, of course):
1) downloading starts immediately, no matter how big the files are;
2) downloaded video files plays with terrible stutters;
3) copying them elsewhere make them play flawlessly;
4) this only applies to high-bitrate files (like BD-Remuxes); DVD's and MP3's are not affected.
I think the conclusion is quite obvious, though I may be mistaking. Sorry, I cannot test your program as I don't have MIPS toolchain for building it. I have tried similar program on my workstation (Yellow Dog Linux on PS3), but it looks that here posix_fallocate is the same as filling with zero's - it takes the same time for both methods to allocate (about 1 min for 1G file).

comment:25 in reply to: ↑ 24 Changed 8 years ago by charles

Replying to hdfan2:

charles: No, I didn't try this yet. I hoped to do this yesterday (with the help of Ger Teunis), but we've run into some problems. Hope today they will be resolved, and I'll test it ASAP. Probably I've reopened this issue too early (sorry), but the problem is definitely there, a lot of people suffering it, and the sooner it'll be defeated the better.

Yeah, you said that already:

This issue is very common in our local NMT community, everyone using T suffers it a lot

All I'm saying is that since I don't have NMT, I'd like one or two people to confirm that the patch actually works before it goes into svn.

comment:26 Changed 8 years ago by Ger Teunis

I've updated the NMT build, this one works (already contacted hdfan2 about it). I must say that I cannot see the fragmentation issues at all and didn't hear about it in the official NMT transmission thread or very infrequent. It is not that I do not believe hdfan2 is seeing the problem, just the problem is not that big (quantity wise) in my opinion. An extra option for those users, who are suffering from it, which they can configure by hand can't be a bad decision I guess.

comment:27 Changed 8 years ago by Ger Teunis

ps> by saying "this on works" I meant: the build was successful.

comment:28 Changed 8 years ago by hdfan2

A quick update: I've successfully installed Ger's build (thanks, Ger!), and so far downloaded one video file - plays smoothly (I've downloaded the same file several days ago, and couldn't watch it without copying). Of course, one file is not enough, so I'm continuing testings. Meanwhile I've made an announcement in our local forum in search for voluntaries, so I hope in a day or two we'll have other independent responses (I've gave a link to this topic).

comment:29 follow-up: Changed 8 years ago by sandeen

hdfan2, it's a pity that you can't test that program. I don't think posix_fallocate ever does anything other than filling with zeros. Making a sparse file does not provide the proper guarantees, and anything other than zero-filling must be explicitly and uniquely supported by the filesystem.

If you can find someone in the NMT community who can build and test a binary, I think you will find that you are indeed getting a 0-filled file from this test, though it may still be somewhat fragmented.

Ger, adding code and a new config option to write 0s by hand is almost certainly unnecessary ... perhaps there is a bug in the maze of #ifdefs such that posix_fallocate() isn't actually getting called either on your build, your platform, or your config. Running strace might be helpful for debugging, if anyone can do that.

comment:30 in reply to: ↑ 29 ; follow-up: Changed 8 years ago by sandeen

Replying to sandeen:

hdfan2, it's a pity that you can't test that program. I don't think posix_fallocate ever does anything other than filling with zeros. Making a sparse file does not provide the proper guarantees, and anything other than zero-filling must be explicitly and uniquely supported by the filesystem.

Oops, I meant "I don't think posix_fallocate ever does anything other than filling with zeros if it can't use preallocation in the filesystem"

comment:31 Changed 8 years ago by charles

My concern with the patch in comment 20 is that there's no guarantee that calling write() in a loop will prevent fragmentation... it doesn't tell the OS upfront how big the file's going to be.

comment:32 Changed 8 years ago by sandeen

Charles, that's right. There is some advantage because it is written in order vs. the random fill-in that transmission would otherwise do. posix_fallocate(), on older kernels or older glibc, does this same write-in-a-loop. I'm lobbying to not replicate that feature in transmission w/o proof that posix_fallocate() isn't actually already doing it .... My main objection to the patch in comment 20 is that I'm 99% certain that it's replicating something glibc can already do for you.

Also, just to note, the goal doesn't have to be perfect fragmentation-free allocation, but to at least avoid the worst-case allocation patterns that can arise if nothing is done to combat it. Write-in-a-loop (whether in glibc or in transmission) will almost certainly give you better results than doing nothing at all.

comment:33 in reply to: ↑ 30 ; follow-up: Changed 8 years ago by hdfan2

Replying to sandeen:

I don't think posix_fallocate ever does anything other than filling with zeros if it can't use preallocation in the filesystem

Right now I've perfomed one more experiment: turned back preallocation=2 and started downloading big file (>30G) (stopped it after a few seconds). Well, it seems that things are even worse than I thought: the file has been created instantly (and had the size required), but the free disk space wasn't reduced. Furthermore, deleting this file was also instant (and deleting already downloaded file takes not seconds, but minutes - more than a minute for 10G!). So, I think this means that files created in this mode are sparse (though it obviously conflicts with the description of posix_fallocate).

Replying to charles:

My concern with the patch in comment 20 is that there's no guarantee that calling write() in a loop will prevent fragmentation... it doesn't tell the OS upfront how big the file's going to be.

Of course, there's no such guarantee. However, it seems that (at least on NMT platform) such write() loop allocates blocks consequentially (instead of randomly in modes 1-2), and this tremendously speeds up reading (due to more efficient read-ahead buffering, I guess). In no way it is "completely prevent fragmentation" option; rather "try and see if it can help". And I have a strong feeling that at least on one platform it helps.

Changed 8 years ago by hdfan2

complete patch for file zero-padding with some additional error handling

comment:34 in reply to: ↑ 33 ; follow-up: Changed 8 years ago by sandeen

Ger, looking at your binaries it seems that there is no call to posix_fallocate in them... can you take a look at your configure/build & see if it's finding posix_fallocate and if not why not?

[esandeen@neon transmission-1.61]$ grep posix_fallocate config.log configure:21854: checking for posix_fallocate ac_cv_func_posix_fallocate=yes

Even if the write loop needs to be added I'd think it could be done as just another case under TR_PREALLOCATE_FULL / preallocateFileFull rather than yet another config option?

-Eric

comment:35 in reply to: ↑ 34 Changed 8 years ago by Ger Teunis

Replying to sandeen:

Ger, looking at your binaries it seems that there is no call to posix_fallocate in them... can you take a look at your configure/build & see if it's finding posix_fallocate and if not why not?

Configure does detect posix_fallocatie correctly, the header and include file is also there in the default location. But I think it might be a mips toolchain issue. Your 'minimal' sample above did not compile correctly, I will have to dive into the toolchain headers to determine why this is happening, the ifdef seemed okay there, I am not very happy that I need to look into this on toolchain level. Soon I will look into this.

comment:36 follow-up: Changed 8 years ago by wishyou

Hey guys!

Again this problem manifests itself on my NAS as well, the Readynas NV+. Downloaded torrents are heavily fragmented. I've used sandeens script to investigate further, and obviously there is something fishy with the posix_fallocate one some platforms.

First of all, preallocating 16 megs does give me only one extent, but increasing the size for the preallocate call to 700Mb, a typical filesize for my torrents, gives me this:

readynas:~/dev-test$ ll
total 64k
drwxr-xr-x    2 xxx      users         16k Jun  3 14:41 .
drwx------   14 xxx      users         16k Jun  3 14:28 ..
-rwxr-xr-x    1 xxx      users         12k Jun  3 14:36 a.out
-rw-r--r--    1 xxx      users         404 Jun  3 14:36 test.c
readynas:~/dev-test$ cat test.c
#define _XOPEN_SOURCE 600
#include <stdlib.h>
#include <fcntl.h>
#include <string.h>
#include <stdio.h>

void main(void)
{
        int fd, ret;

        fd = open("mytestfile", O_CREAT|O_RDWR, S_IRWXU);
        if (fd < 0) {
                perror("file open failed");
                exit(1);
        }
        ret = posix_fallocate(fd, 0, 700*1024*1024);
        if (ret) {
                printf("posix_fallocate failed: %s", strerror(ret));
                close(fd);
                exit(1);
        }
        close(fd);
}

readynas:~/dev-test$ gcc test.c
test.c: In function `main':
test.c:8: warning: return type of `main' is not `int'
readynas:~/dev-test$ ./a.out
readynas:~/dev-test$ ll
total 701M
drwxr-xr-x    2 xxx      users         16k Jun  3 14:41 .
drwx------   14 xxx      users         16k Jun  3 14:28 ..
-rwxr-xr-x    1 xxx      users         12k Jun  3 14:41 a.out
-rwx------    1 xxx      users        700M Jun  3 14:42 mytestfile
-rw-r--r--    1 xxx      users         404 Jun  3 14:36 test.c
readynas:~/dev-test$ sudo filefrag mytestfile
mytestfile: 550 extents found, perfection would be 1 extent
readynas:~/dev-test$

The platform is Debian-Sarge on a SPARC cpu. (Netgear Readynas NV+). I'd say this definitely calls for an explicit zero-fill option.

Wish

comment:37 Changed 8 years ago by charles

wishyou: Thanks for the info. Could you make a test2.c that implements the zero-fill option and see what filefrag thinks of its output?

comment:38 in reply to: ↑ 36 ; follow-up: Changed 8 years ago by sandeen

Replying to wishyou:

...

First of all, preallocating 16 megs does give me only one extent, but increasing the size for the preallocate call to 700Mb, a typical filesize for my torrents, gives me this:

...

readynas:~/dev-test$ ./a.out
readynas:~/dev-test$ ll
total 701M
drwxr-xr-x    2 xxx      users         16k Jun  3 14:41 .
drwx------   14 xxx      users         16k Jun  3 14:28 ..
-rwxr-xr-x    1 xxx      users         12k Jun  3 14:41 a.out
-rwx------    1 xxx      users        700M Jun  3 14:42 mytestfile
-rw-r--r--    1 xxx      users         404 Jun  3 14:36 test.c
readynas:~/dev-test$ sudo filefrag mytestfile
mytestfile: 550 extents found, perfection would be 1 extent

That's ok. Nothing about posix_fallocate guarantees any kind of contiguity; it really only guarantees that you won't run out of space after it succeeds. However, it does give the filesystem a better -chance- at getting contiguous allocations. Depending on your filesystem, where free space is, etc, it could conceivably be very bad. But I'd be surprised if it's worse than nothing at all - as another test, on that same filesystem, remove that "mytestfile" and download a 700M torrent, see what fragmentation looks like there.

But let's not confuse the issue too much here; the real crux of why this bug was reopened, I think, is that posix_fallocate isn't getting configured in, or called, on some platforms I guess.

comment:39 in reply to: ↑ 38 ; follow-up: Changed 8 years ago by charles

Replying to sandeen:

But let's not confuse the issue too much here; the real crux of why this bug was reopened, I think, is that posix_fallocate isn't getting configured in, or called, on some platforms I guess.

Very good point. Let's wait until we hear back from Ger Teunis.

comment:40 Changed 8 years ago by wishyou

Well, I'll be damned for not paying attention to what I do.

It seems, upgrading from 1.50 to 1.61 May, 25th may have solved my problems with fragmentation. Checking the two torrents downloaded after that, (downloads are less frequent now that most seasons are over), shows that extents for a 700mb file dropped from about 40000-50000 extents to less than 10.

Was there a code change that could be relevant here or did any config settings change? Preallocation have been set to 2 all along. Anyway, I'll let this matter rest for now. It seems that this works on my NAS after all.

comment:41 in reply to: ↑ 39 Changed 8 years ago by Ger Teunis

Replying to charles:

Replying to sandeen:

But let's not confuse the issue too much here; the real crux of why this bug was reopened, I think, is that posix_fallocate isn't getting configured in, or called, on some platforms I guess.

Very good point. Let's wait until we hear back from Ger Teunis.

I do not have the time or motivation to look at this at the moment. I've compiled sandeen's code and the result was:

# mipsel-linux-uclibc-gcc test2.c 
test2.c: In function 'main':
test2.c:8: warning: return type of 'main' is not 'int'
/tmp/cc3AS5kW.o: In function `main':
test2.c:(.text+0x9c): undefined reference to `posix_fallocate'
collect2: ld returned 1 exit status}}}

Weirdly, the contents of the include file looks okay:
(I did not study it in detail).

{{{
/* Reserve storage for the data of the file associated with FD.  */
# ifndef __USE_FILE_OFFSET64
extern int posix_fallocate (int __fd, __off_t __offset, size_t __len) __THROW;
# else
# ifdef __REDIRECT
extern int __REDIRECT (posix_fallocate, (int __fd, __off64_t __offset,
                                         size_t __len) __THROW,
                       posix_fallocate64);
# else
#  define posix_fallocate posix_fallocate64
# endif
# endif
# ifdef __USE_LARGEFILE64
extern int posix_fallocate64 (int __fd, __off64_t __offset, size_t __len)
     __THROW;
# endif
#endif
#endif
}}}

If anyone here want's my vmware image for building transmission: I am happy to share it.
Any tips where I should look at now? I am that much into linux-coding and don't have enough free personal time to study it for Transmission.

comment:42 Changed 8 years ago by charles

  • Resolution set to fixed
  • Status changed from reopened to closed

Getting T to run more smoothly on small machines like the NMT is a a big goal here, but after the last couple of comments I don't think this issue can be addressed here. If posix_fallocate() isn't working on Ger's sample program, then it's either an NMT or build config problem, no?

Reverting this ticket's state as "fixed" since that's where it was before this side-issue came along. If this turns out to be a Transmission problem -- or if there's something we can do in Transmission to ameliorate it -- please open a new ticket.

comment:43 follow-up: Changed 7 years ago by Kamil Páral

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version changed from 1.21 to 1.73

I reopen this bug because it is not fixed. I just downloaded Ubuntu CD (700MB) and filefrag reports:

ubuntu-9.04-desktop-i386.iso: 53017 extents found, perfection would be 6 extents

That's 75 fragments/MB.

My system: Transmission 1.73, Ubuntu 9.04 amd64, Ext3

When I start downloading, "ls -lh" and Nautilus reports the file to have full size (700MB) from the start. But the available disk space is not immediately taken and declines slowly throughout the download.

This is a very severe issue for me (the only one I have with otherwise brilliant Transmission program), because I have a very slow notebook disk. When I download ISO image with Transmission, I can't burn it to CD/DVD, because the disk is not fast enough to read it and burning stops frequently. When I download a movie (especially HD), the movie player can't play it, because the disk is not fast enough to read it and playback stutters a lot. Simply put, I always have to copy downloaded files to another location, because they are unusable without that.

I don't know much about preallocation methods and such stuff. I have a simple request - please make it work. I will gladly sacrifice loads of disk space in advance, but make the resulting files usable. It may not be the default behaviour (if you deem it not appropriate), but add an option to make it possible. Thank you.

comment:44 in reply to: ↑ 43 Changed 7 years ago by charles

Replying to Kamil Páral:

I reopen this bug because it is not fixed. I just downloaded Ubuntu CD (700MB) and filefrag reports:

ubuntu-9.04-desktop-i386.iso: 53017 extents found, perfection would be 6 extents

That's 75 fragments/MB.

My system: Transmission 1.73, Ubuntu 9.04 amd64, Ext3

Hi Kamil,

What is preallocation set to in your ~/.config/transmission/settings.json file? The default is 1 (fast) because far too many people running ext3 have complained that the system "hangs" on ext3 during a full preallocation. Changing this 1 to a 2 (full) should reduce fragmentation.

After ext4 has been the default for a cycle or two, 2 (full) will become the default.

More information on settings.json can be found at http://trac.transmissionbt.com/wiki/EditConfigFiles .

comment:45 Changed 7 years ago by Kamil Páral

Thank you, Charles! I had preallocation = 1, after setting preallocation = 2 I have this result:

ubuntu-9.04-desktop-i386.iso: 4597 extents found, perfection would be 6 extents

Which is ten times better than before! It really hanged a little from the start while using the harddisk, but not much and it is certainly a great improvement for me. I hope now I won't have problems with burning/playing movies. Thanks!

(I don't know whether to change status of this bug back to fixed, please adjust appropriately.)

comment:46 Changed 7 years ago by charles

  • Resolution set to fixed
  • Status changed from reopened to closed

Yeah. The default value should be the one that causes the most people the least amount of trouble, and for now preallocation = 1 is that value. When ext4 is more commonplace, that should switch to preallocation = 2.

Note: See TracTickets for help on using tickets.