https://bugs.kde.org/show_bug.cgi?id=438434
--- Comment #11 from tagwer...@innerjoin.org --- (In reply to Martin Steigerwald from comment #10) > ... I hope you understand that I am not willing to change my setup > dm-crypt with LUKS, LVM and then BTRFS (single) on top of it, to be able to > guarantee a stable device number ... Absolutely... However baloo depends on having some sort of "invariant" for a file. Depending on a filename/path would also leave the system vulnerable to the random renaming of large directory trees or remounting something under a different mount point. > ... I do think the device number is not > supposed to be of relevance for any application and is not guaranteed to be > stable in Linux, but I can certainly ask Linux kernel developers about their > take on this ... Search/indexing is somehow "in the middle" between being an application and system software. It seems to need to know deeper stuff (maybe things like Dropbox also need such knowledge) Yes. If there's any magic way of asking for a vol or subvol mount to be "at" a given device number, that would sidestep around the problem. A forlorn, optimistic hope perhaps - but who knows? > Does that mean that Baloo saw two different device numbers (32 and 33)? > > There have been several reboots and it may be that at a certain point the > device number has been different, I just checked for the device number as I > actually noticed Baloo was re-indexing files. So maybe the re-indexing was > triggered by a different device number from a boot in between? I think so... I've no practical experience of your stack but I've see far worse with openSUSE's BTRFS setup 8-/ > But maybe I misread the above output. Anyway, I hope it helps. I'll say thank you for persisting. If you find any workrounds, let us know... -- You are receiving this mail because: You are watching all bug changes.
