https://bugs.kde.org/show_bug.cgi?id=460460
--- Comment #4 from Adam Fontenot <adam.m.fontenot+...@gmail.com> --- (In reply to tagwerk19 from comment #3) > Does it make sense to close this as a duplicate of Bug 437754? Probably not? I tried to keep this bug report focused on the user-facing issue in Baloo. I think you're probably right that the cause of my specific issue was Bug 437754. However, there are a million Baloo bugs for i/o thrashing, memory use, hanging on specific files, incorrect indexing, etc, and one thing that unites them is that the user is put in a situation where they will probably want to kill Baloo. The problem that users regularly encounter is that Baloo claims to be idle and can't be killed. (In my case it even hung the System Settings UI for 30 seconds as well.) Under the assumption that we probably won't have fixed all the issues with Baloo in a year (or five), I think making sure the user is given correct information when it's misbehaving and the ability to stop it is very important. > When it starts up "baloo_file" scans through the filesystem looking for > unindexed or updated files. At the moment it does that in memory, only > committing the results at the end of the process. That means "balooctl" > doesn't > see the work done when it is looking in the database file. It's hard to say for sure what Baloo was doing in my case, but from the `strace` it appeared to be seeking and writing a file. If that's the case then I assume it wasn't merely updating the list of changed files in memory, so that can't be the explanation for why it claimed to be idle. > If you are interested, have a look at: > > https://bugs.kde.org/show_bug.cgi?id=402154#c12 Fortunately I don't mount any subvolumes explicitly, I have separate real partitions (e.g. for root and home) each formatted with BTRFS, and only the default BTRFS subvolume on each file system is mounted in my fstab. -- You are receiving this mail because: You are watching all bug changes.
