Scrap Baloo Thread Feedback

[Dominik Haumann]

Hi all,

CC: plasma-devel, due to stability issues

On Fri, Oct 7, 2016 at 5:56 PM, Christoph Cullmann <cullmann at absint.com> wrote:
> Hi,
>
[...]
> Actually, the bugs.kde.org page tells you the facts: The bug number
> was constant increasing since > 1 year. The thread lists some other facts
> what is wrong ATM and should be fixed.

Btw, the bug count is increasing again, just as before. So it seems
problems remain.

[...]

>> Right now, random requirements such as NFS and 32bit systems are
>> coming up. Are these really that important?

Yes, it is, see below.

>> I specifically designed
>> Baloo to not care about both network mounts and 32-bit systems. Yes,
>> Baloo has bugs and it won't handle more than 32bit-inodes. These
>> things, as all others, can be fixed. It's really a question of what is
>> important. Lets not target the outliers. Many of these decisions were
>> deliberately taken.
> That are no random requirements, sorry, you could call it random restrictions, too.
> That is not that productive, or?
>
> 1) 32-bit systems are still there and if that is a design decision to NOT support them,
> that is ok, but then bad for Plasma, no official support for 32-bit systems, baloo is IMHO
> the only framework with such requirements. And I see not that we have hinted any distro
> that they shall not compile it for 32-bit.
>
> 2) No NFS: Ok, fair game, but then, it should check that and disable itself completely if $HOME
> where the db is stored is a NFS, can live with that, too, but not with the current "we random
> crash" behavior. => That is a user experience we don't want, or?

The reason why I am writing this mail is exactly this point:

At the university where I was previously working, $HOME is mounted via
NFS. After an upgrade from KDE4 to Plasma 5.8, the desktop crashes
very often. And the very reason is baloo.

The problem, however, is that even the sysadmins do not know that
baloo is the reason for all the crashes. In other words: Hundreds of
users probably get the impression of an unstable Plasma 5.8 - or even
worse - it boils down to "KDE sucks" or "I don't have these issues
with Ubuntu".

This is a perfect example of extremely negative impact - the Plasma
devs can work as hard as they want, the desktop in this context will
*never* be stable unless baloo is deactivated.

That said: Baloo needs to disable itself for everything that touches
NFS, or maybe even disable itself after it crashes several times.

There were many more issues listed and discussed, but as far as I can
see, we did not make real advances besides some prototype based on
tracker (just a test), and some minor fixes in baloo that do not
address the hard problems.

Sorry that this reads like a rant. This is not the intention. Instead,
the goal is to underline the still severe issues in order to get
closer to a stable desktop for our users.

Greetings
Dominik



> 3) > 32-bit inodes: That is normal and should work, but even if it should not: Atm you get inconsistent
> and then later assertion fails or crashs.
>
> => I can live with all restrictions but the current handling of them, that always ends in "crash" is
> IMHO not that acceptable. But that is "my" opinion, that might vary in the eyes of others.
>
>>
>> How about requirements such as resource consumption, ease of
>> integration, search speed are taken into consideration? Come on guys.
>> We're engineers over here.
> What is the argument here? If you take a look at bugs.kde.org, you see that people are complaining about all
> of that with baloo. I see no evidence nowhere that e.g. baloo is "superior" to what GNOME uses
> or any other solution (perhaps beside nepomuk, ok...).
>
> I fixed in a few days more bugs than were fixed in 1 year and triaged more than ever, still a lot is to be done.
> (and I did really not do a lot, just remove things like 'self destruct if index > 5GB' or 'crash for ever on
> db corruption')
>
> A graph tells more than words:
>
> https://bugs.kde.org/reports.cgi?product=frameworks-baloo&output=show_chart&datasets=CONFIRMED&datasets=ASSIGNED&datasets=REOPENED&datasets=UNCONFIRMED&datasets=RESOLVED&banner=1
>
> Given the current open bugs, one will need to:
>
> 1) review all extractors, they have still close to zero error handling and will just crash or OOM you on bad files
> 2) review + fix the complete data base handling to handle errors and perhaps swap the DB
> 3) fix the indexer to have some resource limits to avoid OOM and Co. if e..g extractors fail
> ...
>
> Therefore there was my proposal, given we lack manpower, to implement baloo API on top of e.g. tracker to avoid all this
> and let tracker handle that.
>
> To check if that is at all feasible, I did some quick and dirty implementation (still modulo filling of the metadata in the results + tagging,
> which is a problem, but that was only to see if e.g. search works)
>
> https://quickgit.kde.org/?p=clones%2Fbaloo%2Fcullmann%2Ftbaloo.git
>
> That is just a proposal and then I started the discussion.
>
> Until now, we have one other proposal, by Boudhayan, to fixup baloo.
>
>>
>> (If the discussion continues on kde-frameworks-devel, I probably won't see it)
> I won't see it on kde-devel, please, frameworks related stuff should really
> be discussed on the frameworks list.
>
> Greetings
> Christoph