Version: unspecified (using KDE 4.4.3) OS: Linux Heavy i/o with real downloading at low speed, when using ktorrent-4.0 and filesystem is xfs or btrfs (confirmed by another user). works flawlessly with ext4 though. When I download to xfs partition ktorrent downloads only at 1 mb/s of 10-11 mb/s possible. Gui reacts very slow (takes up to 10 sec for button press reaction) during download process. If I change download directory to ext4 partition everything goes normal. I also tried to download with other clients (qbittorrent and ktorrent-3.3.4) and everything is fine with xfs. Here are words of btrfs user: "For me on btrfs ktorrent was downloading at 1 mbit/s (128 kb/s) and responded wery bad to any interaction. also the most of cpu was wasted on waiting for i/o to disk (wait state in top). And in htop or top ktorrent was marked with D - which means it was waiting for io. After changing download location to ext4 ktorrent went to 10 mbit/s, and was responding to my actions without any delays" Reproducible: Always Steps to Reproduce: Start downloading something on xfs or btfs partition. Actual Results: Heavy i/o with slow downloading (not utilizing all available bandwidth) with terrible gui lags Expected Results: Normal downloading with fast gui reaction
I can confirm this with btrfs. Though i thought it's the btrfs's bug, not ktorrent, now i dunno. Some extra info for my issue: 2.6.34-gentoo Intel Celeron 430 Hard drives are connected to this: 00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01) One is 120 Gb ext4 Other is 500Gb btrfs Everything is fine with ext4, and unsuable with btrfs Disks are: WDC WD1600JS-00MHB0 ST3500641AS
It's about time everbody switched to ext4 :-) KT 4.0 when mapping pieces of a file in memory will call posix_fallocate on that piece to ensure the diskspace is there. That way we can detect a disk getting full before attempting to write a piece to it. However this is a rather slow operation for some file systems, and extremely fast for others. Strangely though according to http://log.amitshah.net/2009/03/comparison-of-file-systems-and-speeding.html, xfs and btrfs should be good at this operation. I have already improved things somewhat, however this does not solve it under high write speeds. So I'm currently working on an alternate approach.
(In reply to comment #2) > I have already improved things somewhat, however this does not solve it under > high write speeds. So I'm currently working on an alternate approach. Great, just let us know, when there will be something to test, i'll compile ktorrent form git/svn.
SVN commit 1137278 by guisson: Disable calling posix_fallocate before mapping chunk, it causes to much disk activity on some filesystems BUG: 241339 M +1 -1 ChangeLog M +2 -0 src/diskio/cachefile.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1137278
*** Bug 241154 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > SVN commit 1137278 by guisson: > > Disable calling posix_fallocate before mapping chunk, it causes to much disk > activity on some filesystems > > BUG: 241339 > > > M +1 -1 ChangeLog > M +2 -0 src/diskio/cachefile.cpp > > > WebSVN link: http://websvn.kde.org/?view=rev&revision=1137278 That fixed this issue for me.
I've just build ktorrent from svn and it downloads on xfs partition without any problems. Thanks.