https://bugs.kde.org/show_bug.cgi?id=460460
tagwer...@innerjoin.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tagwer...@innerjoin.org
--- Comment #1 from tagwer...@innerjoin.org ---
(In reply to Adam Fontenot from comment #0)
> 2... probably resulting in the deletion of some
> temporary files. (See the linked bug above describing heavy disk write
> caused by file deletion.)
> 3. Try to check on Baloo's status...
Maybe Bug 437754.
Deleting entries does seem to be hard work, as far as I can tell baloo deletes
entries one by one (rather than working with 40 files at a time as when content
indexing). A "balooctl status" opens the database for reading and while this is
happening, any updates are done as "appends". The database might easily balloon
in size when caught in this situation.
I'm guessing you had been doing content indexing previously and had disabled it
- otherwise 0.5 Gbyte seems a little large. I'd need to check to see whether
baloo "cleans up" content records in this situation or just leaves them
"orphaned".
Maybe Bug 440802
Second thought is that if baloo_file sees a large number of unindexed files, it
first collects the metadata for all of them, then writes the all results to
disc. This can give a sharp peak in memory usage and, in extreme cases, bog
down the system.
Note in this case, the work that baloo_index is doing is invisible to "balooctl
status".
Off-chance thought...
Can you see out what temporary files Audacity creates? Might baloo want to
index them? (Are they hidden or not? what does kmimetypefinder say about
them?). It is an off-chance as if you are not content indexing, this shouldn't
affect you.
Finally...
What filesystem are you using? If you are using BTRFS, there'll be a follow-on
set of questions....
--
You are receiving this mail because:
You are watching all bug changes.
