https://bugs.kde.org/show_bug.cgi?id=438434
--- Comment #15 from Martin Steigerwald <[email protected]> --- One possible drawback for BTRFS could be: In case someone changes the subvolume that is mounted for /home Baloo would re-index files. However… that still would be preferable I think. Also I'd probably combine the statfs() fsid approach which an approach to tell Baloo "/home" or another path is persistent. Actually I think in 99+% of all cases it is. According to what I gathered the device number could change in several cases: - BTRFS and/or LVM are in use and the order of doing things might change. - In a desktop machine with several controllers there would be a driver loading race conditation - Even between different mounts, especially with Systemd, they probably would not be mounted in the same order. BTRFS as well as LVM uses so called "anonymous" device numbers. From what I understand these are dynamically allocated device numbers. These are only valid during run-time. So first step would be: - What for does Baloo need an invariant for the file? - Why wouldn't a rename mess things up without an invariant (device number or filesystem id)? Or otherwise put how would having device/filesystem unique invariant help with a rename? I bet you'd need a file/directory based invariant for that. I.e. a hash value for each file. I think also regarding the energy efficiency goal it would be good to revisit all of this and come up with an approach that avoids clearly needless indexing work. I bet that indexing files and mails is easily the most energy and resource consuming aspect of Plasma desktop and KDE applications. -- You are receiving this mail because: You are watching all bug changes.
