Description of problem:
posix_fallocate not enabled.
files generated by e.g. rtorrent are horribly fragmented.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. download file with e.g. rtorrent
2. type "filefrag importantmovie.avi"
66666 extents found
1 extent found
--- libtorrent.spec~ 2008-08-07 20:20:46.000000000 +0300
+++ libtorrent.spec 2008-10-10 23:28:51.105802467 +0300
@@ -37,7 +37,7 @@
It wasn't as easy as hoped...
But with the attached patch rtorrent successfully calls fallocate as shown by strace, du shows the space is allocated, and filefrag shows 1 extent (at least quite often ;) ).
Created attachment 320068 [details]
force call to posix_fallocate when creating a new file
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
rawhide at least now does:
if (m_flags & flag_fallocate)
so I think we've got the smarts in there. But configure is still not called w/ --with-posix-fallocate. Can the original reporter test & confirm that the config option is all we need now?
Can the package owner chime in? :) We should get this enabled IMHO.
I guess I acquired the package sometime after this bug was first reported, I don't remember getting mail about it. Anyways, I'm happy to enable such a configure option, if it doesn't require a patch to upstream.
I'm not all that familiar w/ rtorrent/libtorrent - in quick testing just the config option didn't make a difference, there was still no call to posix_fallocate.
But I've seen references to rc file setting to enable fallocate as well ... if you know how to actually enable the call to posix_fallocate, maybe you can post it here :)
I don't, sorry.
Possibly relevant is this:
The gentoo maintainer's line of thought makes sense to me.
Right, it can be painful on, say, ext3, but I was under the impression that it could be controlled by a config file. *shrug*
That's what I got from reading the gentoo bug. If users are on ext4/XFS, they can enable it in their config. I think that at least a large percentage of users are on ext3, and we shouldn't enable it by default.
That's fine to leave it disabled in config by default (although, ext4 is now the default fs, but... that's fine...) - point being,
a) enabling it in config doesn't work until we pass the config option anyway, and
b) how do we pass that config option to test it? :)
Ahhhhh, ok, I misunderstood. My understanding was that there was no such config option, and it was enabled purely at run-time based on the config option.
"To try it out, configure with '--with-posix-fallocate' and set 'system.file_allocate.set = yes'." 
But this refers to svn head 6 months ago -- I don't know if we have it in 0.12.5.
: http://libtorrent.rakshasa.no/ticket/460 (about 5/6 of the way down the page)
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.
More information and reason for this action is here:
(In reply to comment #13)
> Re: a)
> Ahhhhh, ok, I misunderstood. My understanding was that there was no such config
> option, and it was enabled purely at run-time based on the config option.
> Re: b)
> "To try it out, configure with '--with-posix-fallocate' and set
> 'system.file_allocate.set = yes'." 
> But this refers to svn head 6 months ago -- I don't know if we have it in
A couple of month after your comment, a comment on the ticket explicitly listed support in 0.12.5:
On the other hand, people are reporting incorrect behavior on ext4. Should this be enabled anyway, and users can decide whether to switch it on in their rtorrent configuration depending on which filesystem they use?
e.g. use it on ext3, probably not on ext4, and use it on btrfs. I'll build a patched libtorrent, but not push it to Bodhi, so we can test this.
Tested the patch and with --with-posix-fallocate and system.file_allocate.set = yes the number of extents created is hugely reduced on ext4. It looks safe to thus push out the changes.
Thanks to delta RPMs, making patches smaller, I'll also push out a new rtorrent build that has the system.file_allocate.set added to the sample configuration file
rtorrent-0.8.6-4.fc13,libtorrent-0.12.6-2.fc13 has been submitted as an update for Fedora 13.
rtorrent-0.8.6-4.fc14,libtorrent-0.12.6-2.fc14 has been submitted as an update for Fedora 14.
(In reply to comment #15)
> On the other hand, people are reporting incorrect behavior on ext4. Should this
> be enabled anyway, and users can decide whether to switch it on in their
> rtorrent configuration depending on which filesystem they use?
Out of curiosity what kind of incorrect behavior?
rtorrent-0.8.6-4.fc14, libtorrent-0.12.6-2.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update rtorrent libtorrent'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/rtorrent-0.8.6-4.fc14,libtorrent-0.12.6-2.fc14
rtorrent-0.8.6-4.fc13, libtorrent-0.12.6-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
rtorrent-0.8.6-4.fc14, libtorrent-0.12.6-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.