https://bugs.kde.org/show_bug.cgi?id=434926
--- Comment #17 from nyanpasu64 <nyanpas...@tuta.io> --- (In reply to tagwerk19 from comment #15) > > mdb_dump -a . > The rationale is that being able to dump the database gives you a necessary > (although not sufficient) test that the index is OK? Nice ;-) It's fairly effective at detecting structural errors, though it won't detect blocks marked as free on-disk while referenced, or (*if* the database is designed to be a tree) blocks referenced twice. It also doesn't check logical consistency of Baloo's database (though the issue here is corrupted/swapped pages/blocks, not logical inconsistency of data). > I see there are bugs resurfacing mentioning MDB_BAD_TXN (Bug 406868), I > wonder if these are related... I do suspect so. > I see the behaviour of baloo grabbing space and not releasing it; the index > gradually increases in size with time. I'm not so worried about the disc > usage but that "rather sparse" data might be pulled into memory is not so > good. > > There is the option to copy/compress the database: > mdb_copy -n -c index index.new > Sometime this does well, sometimes just so-so... Noted. > It might be worth confirming you hit trouble with the database on an ext4 > filesystem (and not BTRFS where I'd want to know that COW is disabled on the > directory). I'm on btrfs, lsattr ~/.local/share/ shows baloo as C (nocow), and lsattr ~/.local/share/baloo shows both index and index.lock as C (nocow). -- You are receiving this mail because: You are watching all bug changes.
