Re: Debian Testing KDE/Plasma 6: Baloo
Hi.
Jetzt gebe ich doch mal meinen Senf dazu:
Marco Möller - 27.04.25, 13:20:16 CEST:
> On 26.04.25 2:22 PM, Philipp Ludwig wrote:
> > soll der Index zur Suche verwendet werden? Wenn nicht,
> >
> > $ balooctl6 suspend
> > $ balooctl6 disable
> >
> > Um den Indexer zu deaktivieren, und
> >
> > $ balooctl6 purge
>
> Allerdings, Baloo könnte auch an der Verwaltung der Datenbank von KMail
> und KDE's Adressbuch beteiligt sein, allgemein an allem was auch PIM
> genannt wird, oder auch sonst wo. Baloo ist, wie ich es verstanden habe,
> eine KDE eigene Datenbank, und daher muss man einfach davon ausgehen,
> das alle möglichen KDE Prozesse und Apps, die eine Datenbank benutzen
> wollen, darauf zurückgreifen. Ich lasse mich gerne korrigieren, wenn
> ich das falsch beobachtet habe.
Baloo ist der Desktop-Such-Index.
KDEPIM inklusive KMail, allerdings nicht Akregator, das Metakit nutzt,
greift auf Akonadi zurück. Akonadi hat auch einen Such-Index. Der liegt
woanders: unter „~/.local/share/akonadi/search_db“. Die eigentlichen
Verwaltungsdaten landen mittlerweile standardmäßig in einer SQLite3-
Datenbank. Zuvor war MariaDB Standard. Debian 12 nutzt standardmäßig noch
MariaDB. Ab Debian 13 kommt SQLite3 zum Einsatz. Bestehende Installationen
migriert Akonadi nicht automatisch.
Es gab meiner Erinnerung nach tatsächlich eine gemeinsame Lösung für die
Such-Indexe in Baloo und Akonadi. Das ist jedoch längst nicht mehr der
Fall. Auch in Debian 12 bereits nicht mehr. Der Such-Index für Akonadi ist
mittlerweile getrennt, basiert jedoch meines Wissens auf derselben
grundlegenden Technologie. Die Entwickler haben den ausgelagert.
Baloo ist daher nicht Akonadi und auch umgekehrt wird kein Schuh draus.
Baloo läuft seit einiger Zeit sehr gut auf meinem Laptop. Und das auf
BTRFS, wo es zuvor das Problem gab, dass es Dateien immer wieder neu
indizierte. Mit gut 1,1 Millionen Dateien, Volltext-indiziert in einem
Index von knapp 10 GiB. Das ist auf einem modernen ThinkPad mit 32 GiB RAM
und 4 TB schnellen NVME-Speicher.
Es gibt eine Reihe von Wegen, genauer unter die Haube zu schauen. Dazu die
Manpage von balooctl6 anschauen, z.B. nach „index“, „clear“, „indexSize“,
„failed“ und „monitor“. Und schauen, was im Community Wiki steht. Den Link
hat Christoph ja bereits gepostet. Mit „clear“ und dann „index“ konnte ich
zuletzt einige mit „failed“ angezeigte Indizierungsfehler lösen.
Von den knapp 10 GiB nutzt Baloo laut "indexSize" angeblich weniger als 1
GiB. Anders als bei der SQLite3-Datenbank von Akonadi kenne ich derzeit
keinen Weg, da drin aufzuräumen: Außer mit „purge“ den alten Index zu
löschen und Baloo einen neuen Index aufbauen zu lassen. Das kann ein
valider Weg sein, um etwaige Altlasten im Index aufzuräumen. Das habe ich
in der Phase, wo es deutliche Verbesserungen an Baloo gab ab und zu
gemacht. Je nach Hardware und Daten-Menge kann das jedoch sehr lange
dauern. Unter bestimmten Umständen löst Baloo jedoch laut Quelltext
offenbar auch automatisch eine Art Migration aus. Nach einem Neu-Aufbauen
des Index kann Baloo den aber wieder aufblähen. Über 340 GiB ist aber doch
etwas arg, das hatte ich noch nicht.
Zudem gibt es die Möglichkeit, Baloo so einzustellen, dass es nur
Dateinamen, nicht Inhalte indiziert. Das kann hilfreich sein, falls es
nicht gelingt, herauszufinden bei welchen Dateien Baloo durcheinander
kommt. Das habe ich in der Zeit gemacht, als auf meinem privaten Laptop,
auf dem sehr viele Dateien gespeichert sind, Baloo immer wieder mal
meinte, alle Dateien seien neu. Mittlerweile nutze ich auch auf meinem
privaten Laptop die Volltext-Indizierung. Und das ist durchaus praktisch,
um Dinge wieder zu finden. Allerdings ist die Indizierung nach Dateinamen
um Einiges schneller fertig mit dem Aufbau des Index.
Selbst der Akonadi-Such-Index ist seit meinem Umstieg auf SQLite3, der
derzeit leider offenbar nicht mit dem Datenbank-Migrator von Akonadi
funktioniert¹, so stabil, dass ich Akonadi alle Mails indizieren lasse.
Akonadi läuft auch mit SQLite3 bei mir nicht perfekt, aber doch deutlich
besser als zuvor mit PostgreSQL. Das ist die dritte für Akonadi nutzbare
Datenbank.
So Florian, damit dürftest Du für Baloo jetzt Einiges zur Verfügung haben,
was Du durchprobieren kannst. Falls nichts Anderes geht, würde ich die
Indizierung einfach auf „Nur Dateinamen“ umstellen. Das reicht für viele
Fälle. Ein „locate“ schaut ja auch nicht in Datei-Inhalte. Oder wie
empfohlen z.B. mit Recoll eine alternative Lösung verwenden und hoffen,
dass die funktioniert.
Zur Klarstellung habe ich einige Details zu Akonadi erläutert. Das läuft
nämlich mittlerweile getrennt.
[1] Der stürzt laut Berichten auf debian-kde ab. Ich habe dort auf
Englisch jedoch einen Weg aufgeschrieben, wie eine Migration prinzipiell
möglich ist. Es gibt jedoch in Grenzfällen aufgrund der Arbeitsweise von
Akonadi ein Risiko, (wenige) Metadaten zu verlieren.
Ciao,
--
Martin
Reply to: