https://bugs.kde.org/show_bug.cgi?id=380456
--- Comment #31 from Adam Fontenot <adam.m.fontenot+...@gmail.com> --- For what it's worth, 15 minutes after I posted my comment about i/o, it had gone up to 600 GB written by baloo_file (another 100 GB), and I stopped it with `balooctl suspend` followed by `balooctl disable`. Unfortunately, as I've gotten used to in the past, Baloo claimed to have suspended, but baloo_file continued using 100% CPU and wrote another 50 GB (!) to disk before I gave up and did `kill -9` as usual. I've given up on testing for the time being. > I think it commits file by file after deletes. It's possible that this is related, but I find it hard to believe that any reasonable database format would need to write 150+ GB to disk to delete entries from a database that was only 8 GB, even if you deleted every single entry in the database one at a time. Whatever the reason, it's also very frustrating to see Baloo hang (and not respond to requests to suspend, see above) after a perfectly normal activity like deleting some development files. (One entirely theoretical possibility is that Baloo is performing "vacuuming" on the LMDB database after every single deletion, i.e. rewriting the database to release the cleared space back to the file system. Needless to say, this would be a terrible idea, so it doesn't seem very likely? But there are variations that seem more sane at first glance, but actually aren't, like vacuuming after every 1000 deletions.) I'm willing to re-test if someone wants to provide a patch to batch up deletes in baloo_file. > Possible that baloo_file was killed OOM, there might be hints in the journal. > I tend towards a MemoryHigh limit of 25% rather than 512M. Not clear whether this happened. It appears to have hung ~20 minutes after I started it, but I don't see any direct evidence of a crash. When I checked the next day baloo_file and baloo_file_extractor weren't consuming any CPU and the UI showed progress stuck at ~23%. This is more of a question, but what is the *intent* behind the 512MB memory limit? I think that's an entirely reasonable upper bound on a file indexer, personally, but I'm not sure what's supposed to happen when indexing some file would cause the indexer to exceed that. It is supposed to intelligently skip the file? Crash and then continue with another file? Hang entirely and no longer make progress? -- You are receiving this mail because: You are watching all bug changes.
