https://bugs.kde.org/show_bug.cgi?id=402154
--- Comment #19 from Kai Krakow <k...@kaishome.de> --- BTW: Such a UUID-to-deviceId mapping table would allow baloo to properly support most yet unsupported filesystems, probably also zfs. With such an idea implemented, the only requirement left to a supported filesystem would be that it has stable inodes across re-mounts/re-boots (most have, some don't) and supports reverse lookups (inode to path). The problematic design decision is how baloo identifies files: each file is assigned a devId/inodeId number (each lower 32-bit only, combined into a 64-bit fileId). If this magic number changes (that happens in zfs, btrfs, nfs...), the file appears as new. But neither Linux nor POSIX state anywhere that this can be used as an id to uniquely identify files - unless you never remount or reboot. Also, re-used inode numbers (especially after clipping at 32 bit) will completely mess up and confuse baloo. So this needs are multi-step fix: First (and most importantly) introduce virtual deviceIds by implementing a mapping table "volume/subvolId <-> virtualDeviceId" where virtualDeviceId would be a monotonically increasing number used uniquely throughout the index as a device id. Next step: Enlarge fileIds from 64 to 128 bit, so it can be crafted from 64-bit devid/inode without clipping/wraparound. On the pro side, such a mapping table would also allow to properly clean up index data from the DB for file systems no longer needed. Currently, baloo never knows if a file system would appear or doesn't. This could be implemented in one of the later steps as some sort of housekeeping optimizations. -- You are receiving this mail because: You are watching all bug changes.
