https://bugs.kde.org/show_bug.cgi?id=402154
Kai Krakow <k...@kaishome.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |k...@kaishome.de
--- Comment #18 from Kai Krakow <k...@kaishome.de> ---
(In reply to tagwerk19 from comment #17)
> Looks as if this is a long term issue...
> Scroll down to the last posts in Bug 404057
Yep, this problem has already been deeply analyzed and is well understood. The
referenced bug report includes a lot of thoughts, possible solutions, and also
a few real improvements as patches - some of those were merged. There are also
links to phabricator with extended discussion. I suggest to read that entirely
to understand the problem (some later comments re-decide on previous thoughts).
Sadly, I mostly lost interest in this issue in favor of other more important or
personal stuff. I simply ditched baloo since then as I wasn't really using it
anyway that much.
But if anyone wants to take the effort in crafting any patches, they might want
to start with implementing the mapping table from volume/subvolume UUID to a
virtual device number - and that virtual device number would than be used
instead of the real one. This way, a distinct file system would always show up
as the same device number in baloo - no matter on which device node it
appeared. It solves almost all of the problems mentioned here. I volunteer to
mentor/help with such an implementation, I'm just too bad with Qt/KDE APIs to
kickstart that myself.
Later improvements should look at access patterns and how to optimize that,
maybe LMDB can be used in a better way to optimize it for background desktop
access patterns, otherwise it may need to be replaced with some other backend
that's better at writing data to the database (aka, less scattering of data
over time): LMDB is optimized for reads and appends, much less for random
writes (but the latter is the most prominent access pattern for a desktop
search index). So if we stay with LMDB, baloo needs to be optimized to prevent
rewrites in favor of appends - without blowing up the DB size too much. It may
mean to purge still existing data from the LMDB mmap in favor of a bigger
continuous block of free DB memory. Also, aggressive write coalescing is needed
to avoid fragmentation access patterns in filesystems.
--
You are receiving this mail because:
You are watching all bug changes.
