<table><tr><td style="">hurikhan77 updated the task description. <a href="https://phabricator.kde.org/transactions/detail/PHID-XACT-TASK-ysynctzsyr5qiko/">(Show Details)</a>
</td></tr></table><br /><div><strong>CHANGES TO TASK DESCRIPTION</strong><div><div style="white-space: pre-wrap; color: #74777D;"><div style="padding: 8px 0;">...</div>2. After having outlined (1), let's see what could be fixed: Baloo should migrate to using its own device id database. That could be easily coded by adding another table to the database which stores a mapping of device id to filesystem uuid. The nice aspect of this approach is that we could just map the currently known device ids at table creation time and all the database entries stay compatible. Newly added devices would then allocate a free device number from this table and remember the uuid, reappearing device would match the uuid and use the device id mapped in the table. This will fix all file systems with unstable device ids (according fstat call). But it will not fix file systems with unstable inode numbers. Also, there's a problem with modern filesystems using 64 bit inode numbers: Baloo only has 32bit (device id) + 32bit (inode id) for file mapping, it currently just discards the upper 32bit if they exist. This is okay most of the times but creates a new set of problems.<br />
<span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);"><br />
3. </span>While the Baloo database is using lmdb and that database system is very powerful, it is not tuned optimally when used as a background service. Actually, I don't believe lmdb was designed to work as a background system but all it's other properties are very well designed. I already submitted patches to tune some of the parameters, i.e. disable read-ahead as it is mostly useless for Baloo and how it uses the database. This reduces file system cache thrashing. And actually, that is what you want to care most about: Baloo should be able to tell the system early that it no longer needs some data in cache.<br />
<br />
<span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">3</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">4</span>. When the Baloo database grows very large, this may become problematic for the kernel. While lmdb actually doesn't really use memory (it's memory mapped and works more like the swap file), it still maintains a good amount of page table space. Especially in combination with components that do a lot of memory allocations (like btrfs), this introduces a vast amount of micro latencies and puts the memory manager under pressure. We will probably also see high memory fragmentation due to a lot of small allocations needed from lmdb. Memory compaction, when needed and running, will be observed as severely affecting interactive response of the system. And it may even lead to early out of memory situations for some hardware that needs contiguous memory allocations (mostly GPU applications). So it's important to keep the memory footprint of lmdb as low as possible. But that's not really possible as lmdb needs to map the whole database all the time. But it may be possible to start with a small database file and dynamically grow it when running out of space. But lmdb is not designed to do this while the database is opened, and Baloo probably needs some redesign to do this as far as I understood the source code.<div style="padding: 8px 0;">...</div></div></div></div><br /><div><strong>TASK DETAIL</strong><div><a href="https://phabricator.kde.org/T11859">https://phabricator.kde.org/T11859</a></div></div><br /><div><strong>To: </strong>hurikhan77<br /><strong>Cc: </strong>Frameworks, bruns, Baloo, hurikhan77, lots0logs, LeGast00n, cblack, fbampaloukas, domson, ashaposhnikov, michaelh, spoorun, ngraham, abrahams<br /></div>