Re: [kde-linux] baloo_file_extractor - huge disk usage?
- Date: Fri, 14 Aug 2015 00:02:06 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: [kde-linux] baloo_file_extractor - huge disk usage?
Mark Knecht posted on Thu, 13 Aug 2015 14:36:35 -0700 as excerpted:
> I'm not sure if this is a Gentoo issue or a KDE issue so I'll start
> on the KDE list. Thanks in advance.
Arguably, it's a kde as upstream issue, but gentoo offers the possibility
of mitigating it, arguably more than most binary distros. =:^)
> I have a problem that's developed recently. The basic symptom is
> the machine slows down horribly at some point in the afternoon with the
> disk activity light is full on - no blinking at all. This results in all
> applications - Virtualbox, Chrome, etc. - essentially ceasing to operate
> correctly and KDE to sometimes locking up for 5-10 minutes.
> Due to recent messages from Gentoo devs requiring baloo I've started
> looking there.
> When I'm in this state where disk activity appears to be 100% I see
> large wait percentages in top. (3 CPUs in this state right now.) Running
> iotop it appears that something called baloo_file_extractor is spending
> 99.9% of its time waiting.
Yeah... that behavior is why I decided the (small to me) benefits of
semantic-desktop in general weren't worth the down side. Tho the
tradeoff is arguably different for each person/use-case, the basic
problem remains the exact same one it was back before the turn of the
century, when the first thing most computer-knowledgeable folks did to
an MS Office installation was disable its indexer functionality.
> While writing this message the disk light has gone back to no
> activity, the machine is responsive and the baloo_file_extractor app is
> no longer using io.
> So, the basic question is how do I turn this off or at least get it
> under control as it's causing huge problems when it occurs?
> If this isn't the right list please advise where is better. Maybe
> it's a distro issue.
While it might be possible to throttle baloo to some extent (I'm not
actually sure because like the nepomuk before it, it's banished from my
system), and at least back in the nepomuk era when I rid myself of it, it
was in theory possible to turn off at runtime, at least in my experience,
actually building kde with USE=-semantic-desktop (obviously not an option
on distros where the binaries come pre-built, thus my remark above about
gentoo making a workaround easier) and without related flags and packages
, then depcleaning them from the system, made kde *SURPRISINGLY*
faster. "Surprisingly", because I /thought/ the runtime turnoff actually
did so, and the build-time disable and depclean was primarily to clean up
the dependencies. But /something/ was obviously still sucking
performance as I'm not kidding, after getting it off the system entirely,
it was as if I suddenly had a couple extra cores or had upgraded at least
a half a GHz in cpu speed, which REALLY surprised me. It felt like I
guess the MS users must feel after they get the malware cleaned off!
While I can't guarantee similar effects to everyone, ridding your system
of semantic-desktop and the baloo indexer and akonadi, should at minimum
guarantee that it won't run and effectively lock you out of normal
operations on your system for minutes at a time.
And actually, the gentoo/kde devs have recently cleaned up the old
akonadi deps in the old pre-akonadi-kmail kdepim-4.4.x series as well, so
you shouldn't even require akonadi and via it, semantic-desktop, for the
non-akonadi kmail/kdepim stuff, either. The other alternative being to
switch to non-kdepim solutions for mail and related (IM, feed-reader,
etc). I've been rather happy with claws-mail since I switched to it
here, altho the migration from kmail isn't as simple and easy as I would
If you have detail questions and would prefer to take it to the gentoo-
desktop list (or gentoo-amd64, but the desktop list is more topical),
that's fine, or continue here if you like, since it /is/ kde-linux
related, and I'm on both this the kde-general and kde-linux lists and
those gentoo lists.
 MS at the turn of the century: I haven't allowed MS on my systems
since the introduction of eXPrivacy shortly after the turn of the
century, as it crossed a line I simply wasn't going to cross. Funny that
many of the people who objected to eXPrivacy back then, like frogs in a
heated pot, are now swearing by eXPrivacy, as MS Windows 10 goes even /
further/ down that path. I guess MS is counting on them to protest a bit
as they did last time, but ultimately, continuing to sit in the pot until
they're well boiled. <shrug> Well, I for one, didn't! For that reason
I've little knowledge beyond what I read of what MS does today, nearly a
decade and a half later.
 Semantic-desktop related flags/packages: Back then, rasqual,
virtuoso, nepomuk, akonadi, etc, some of which will no longer be valid
with baloo, but I'm not sure if the deps have actually gone away or have
only been replaced with other deps. I did have to keep strigi as some kde
packages (kdelibs and kde's systemsettings are the two I have installed
that still dep on it) apparently link to its headers without a disable
option, but with all its backends turned off, it couldn't actually do
anything, so other than having to still have it installed to link to,
it's pretty impotent.
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
More info: http://www.kde.org/faq.html.