https://bugs.kde.org/show_bug.cgi?id=402154
Pierre Baldensperger <pierre.baldensper...@numericable.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pierre.baldensperger@numeri
| |cable.fr
Version|5.53.0 |5.57.0
Platform|Neon Packages |openSUSE RPMs
--- Comment #1 from Pierre Baldensperger <pierre.baldensper...@numericable.fr>
---
Yes, I have been observing very similar behaviour with many previous baloo
versions for years, and up to the latest 5.57 (I use OpenSuSE Leap 15.0 with
latest KDE packages from the "KDE Frameworks 5" repositories). To make it clear
: it is not merely resetting the index, it is endlessly accumulating duplicates
of it. Very symptomatic : upon _each_ reboot, the file counter (in "balooctl
status") is _exactly_ _increased_ by the actual number of files, and indexing
seems to painstakingly rebuild and append a new duplicate index each time, not
realizing that these are indeed the same files it had already indexed before
the reboot. I suspect it would behave the same after launching a "balooctl
check" but I never tried this.
I should mention that I use a BTRFS file system so this might be part of the
problem (and why so few people seem to experience the same issue). Maybe there
is some misunderstanding between baloo and the way BTRFS reports or sets file
attributes to identify them as "already indexed" ? I can't remember for sure,
but I don't seem to remember seeing this problem before I switched to the BTRFS
file system (I was using EXT4 previously, more than 2 years ago) : there were
definitely problems with baloo at the time (crashes and such), but I don't
remember seeing the same symptom of duplicate indexing. I have seen that there
is a distinct bug report about suspiciously similar BTRFS problems :
https://bugs.kde.org/show_bug.cgi?id=401863
Of course, reboot after reboot, this behaviour triggers a never ending increase
of resource bloat, not mentioning hours of slowdown after each reboot due to
high CPU and memory load while the indexer browses again all the files to add
an Nth duplicate to its index. At this stage, I would at least like to work
around the problem by performing only a first-time indexing run and then stop
the file content indexer while still being able to search the index (in krunner
of dolphin). But unfortunately I never found any working way to reliably stop
the file content indexer and still use the search engine (shouldn't one of
"balooctl stop" or "balooctl suspend" allow this ?), so the only option seems
to disable baloo completely and lose its search abilities. Moreover, in my
experience, once the file content indexer has been started, the only way to
really stop it is to kill the "baloo_file" process manually : otherwise it will
survive all "balooctl" commands including "balooctl disable". Maybe this part
belongs in a separate bug report : here also I found other similar bug reports
complaining about "balooctl" not actually stopping or suspending "baloo_file"
operation :
https://bugs.kde.org/show_bug.cgi?id=404121
https://bugs.kde.org/show_bug.cgi?id=353559
But none of these reports mentions that the search engine should remain usable
even after the file content indexer has been stopped / killed. Also the file
_content_ search should remain operational even after the file indexer has been
instructed to stop indexing file content (in my experience, disabling the "file
content indexing" option also immediately reduces the search scope to file
names only, despite the existence of a recent content index). Or did I miss
something about baloo search usage ?
--
You are receiving this mail because:
You are watching all bug changes.
