https://bugs.kde.org/show_bug.cgi?id=440802
--- Comment #4 from [email protected] --- (In reply to irchaika from comment #3) > Is there any way to manually trigger a situation that'd make baloo return > the memory? Might be worth having a look at iotop to see if it is writing to disc... What I normally see (and hope is the case here), is that baloo_file has pulled the pages of the memory mapped file into memory as part of the "have I indexed this?", "have the modified dates changed?" initial scan. If nothing's changed these pages are "clean" and don't need to be written back to disc, they just get quietly forgotten when something else needs the space. It's the same as disc cache when you haven't edited a file... If something's happened that means that baloo_file needs to update its basic info, then the changes will be gathered together and written back in a big transaction. We'd need to find out what that change was, but from what you say, the baloo_file_extractor is not working hard so baloo is not having to reindex a lot of file content. There's a chance that baloo is trying to catch up after it's discovered you've deleted a large number of files and it removing the entries in the index. "balooctl indexSize" will tell you how big your index is, both as how much space is taken on disc and real data... -- You are receiving this mail because: You are watching all bug changes.
