On 2014-09-19 08:25, Swâmi Petaramesh wrote:
Well, part of your problem might be KDE itself, it's extremely CPU intensive these days. I'd suggest disabling the 'semantic desktop' stuff, because that tends to be the worst offender as far as soaking up system resources. Also, if you recently switched to systemd, that may be causing some slowdown as well (journald's default settings are terrible for performance)Le vendredi 19 septembre 2014, 13:18:34 Rob Spanton a écrit :I have a particularly uncomplicated setup (a desktop PC with a hard disk) and I'm seeing particularly slow performance from btrfs.Weeelll I have the same over-complicated kind of setup, and an Arch Linux BTRFS system which used to boot in some decent amout of time in the past now takes about 5 full minutes to just make it to the KDM login prompt, and another 5 minutes before KDE is fully started. Makes me think of the good ole' times of Windows 95 OSR2 on a 486SX with a dying 1 GB Hard disk...
It's kind of funny, but I haven't had any performance issues with BTRFS since about 3.10, even on the systems my employer is using Fedora 20 on, and those use only a Core 2 Duo Processor, DDR2-800 RAM, and SATA2 hard drives.Now, let me add that I had removed all snaphots, ran a full defrag, and even rebalanced the damn thing without any positive effect... (And yes, my HD is physically in good shape, SMART feels fully happy, and it's less than 75% full...) I've been using BTRFS for 2-3 years on a dozen of different systems, and if something doesn't surprise me at all, it's « slow performance », indeed, although I'm myself more accustomed to « incredibly fscking damn slow performance »...
HTH
smime.p7s
Description: S/MIME Cryptographic Signature
