My favorite activist 
Shoud I check select all mountpoints or just / ?
I believe BTRFS is the future. Unfortunately I am stuck with EXT4 because when I tried BTRFS Baloo was indexing my /home and every snapshot of it, so it was indexing all the time (making it so unresponsive and many results for the same unique file)
I really hope there is a solution to this issue. Either Baloo find a way or BTRFS find a way or both communicate and find a way for both to play nice together.
For now, the only thing that can be done is to have BTRFS for system and EXT4 for data.
Living and hoping!
Mixing both different filesysstems (Ext4 and Btrfs) in the disk is best option for you if you need Baloo for searching many books.
If you have a 1 TB hard drive in your computer that supports UEFI.
- Boot partition: 300 MB, FAT32 for
/boot/efi - System and home partition: 300 - 400 GB, BTRFS for
/and/home/you(your work data, important data and config data) - media partition: 300+ GB, EXT4 for
/home/you/books(for Baloo),/home/you/Downloads,/home/you/gamesand/home/you/media - Swap partition: ??? GB Swap that depends on RAM size
If you have second hard drive, you can create 300 GB partition for btrfs backup.
This is the point. I have lots!
But I do not mind considering another indexed search other than Baloo if it does not create this problem.
Mine is much less, but I have a lot of free disk space as I donât really have movies or music
Drives:
Local Storage: total: 232.89 GiB used: 48.36 GiB (20.8%)
ID-1: /dev/sda vendor: Samsung model: SSD 870 EVO 250GB size: 232.89 GiB
speed: 6.0 Gb/s type: SSD serial: S5Y4NJ0R325556E rev: 1B6Q scheme: GPT
Partition:
ID-1: / size: 227.88 GiB used: 47.02 GiB (20.6%) fs: ext4 dev: /dev/sda2
ID-2: /boot/efi size: 299.4 MiB used: 464 KiB (0.2%) fs: vfat
dev: /dev/sda1
Swap:
Alert: No swap data was found.
Maybe something other than Baloo that plays well with BTRFS (so I can benefit from all BTRFS features regarding managing space)
But I donât mind mixing BTRFS and EXT4 (tried once but it didnât go smooth in mounting/handling the EXT4 partition)
If you donât use baloo, you wonât get all the integration with kde/plasma/dolphin.
Sure! But I do not mind sacrificing Baloo and use another indexed search app if it plays well with BTRFS.
If it is the same I better stay on EXT4 altogether or mix BTRFS and EXT4 as you suggested to me in another post and as @Zesko suggested.
If I mix I have to seek expert advice about the details of partitioning/fstab⌠etc⌠(as I did it once but EXT4 "behaviour seemed a bit strange for me, mounting/copying/editing/deleting filesâŚ)
I read somewhere that in BTRFS I can exclude /home from being snapshot OR RESTRICT snapshots to system ONLY⌠(so this will avoid the problem? I donât really care about taking snapshots of my /home as all my data are on the cloud)
Here,
If/when you are ready for your ext4/btrfs system, probably better to start a separate topic for it.
Same thing for if you want to discuss alternative indexing options. Might make sense to start a separate topic for that.
You can certainly control what you take snapshots of but that wonât fix the baloo issue, it doesnât appear related to snapshots.
1 Like
Sure⌠Just the conversation developed this way.
I apologise!
The problem here is that /home shouldnât be snapshotted, not Baloo itself.
First of all that is 100% untrue. Snapshots of /home can be very useful and there is no reason not to snapshot all or part of /home if that is your preference.
Second, I donât believe the issue with baloo is actually related to snapshots. It seems to be a design flaw in baloo itself that impacts several filesystems including btrfs.
Either way, lets try to get this topic back on track. baloo issues really donât belong here.
1 Like
I use btrfs but Iâm happy to use ext4 or xfs also. I donât do ntfs. 
You donât need to index your files in order to search effectively. File indexing is, in my opinion, a stupid concept. Especially Baloo â itâs utter rubbish. I always disable it within the first minute of installing KDE.
Just use find, or even better fd.
Why do I think file indexing is stupid?
File indexing is unnecessary â you save maybe a second or two when searching for files (if you have a slow HDD, on SSD, the benefit is even less). If you organise your storage well, you can narrow it down a few levels in a directory tree, cutting the search time exponentially. For example, itâs silly to start searching for a document at the / level of your filesystem, when you know it is somewhere in your userâs home directory and you can probably narrow it down even more. So if you know that, indexed searching is only marginally faster.
File indexing is resource intensive. Even on fast computers, you notice a hit in performance with KDE if Baloo is running, on slow laptops, itâs makes a huge difference.
File indexing is a potential security risk (this is more true for servers). Regardless, having a file containing a list of all your files and their locations is making my tinfoil hat itch.
2 Likes
I am agreeing with the wisdom of the frog. As a test I took 2.2GB made up of 250 PDF OâReilly books with a page count range of 900-1200 per book. It took 1s to locate a keyword that appeared throughout the books, not in the file name, but in the document itself. So weâre so busy today, we canât spare a few seconds to search
Of courise if you have files spread all over the computer, thatâs difficult, but it speaks more to the userâs file organization.
Now you mention it, thaaaatâs a pretty scary thought that an an intruder could get hold of a fully indexed file of your entire computer. More scary is how they get in. Thatâs got nothing to do with indexing, but security.
Nice post 
3 Likes
It depends what you are searching. If you are doing content searches on a large volume of PDF documents, an index will make a huge difference.
Even with filenames, if you have a very large number of documents it can make a significant difference.
Wow, thatâs really fast. Are you sure it wasnât indexed?
I mean, when doing content search on PDF documents, 1 minute per GiB seems pretty damn fast on an HDD, and 10-20 seconds is very good for an SSD, but 1 second⌠To search through it all? That seems a bit too fast even for indexed search. What kind of drive do you have?
How did you do that search out of curiosity?
Nope, not indexed. Maybe the 1s is being kind. I reran it at 7 seconds. Still, Iâm not a data scientist or researcher, so a few seconds here or there is nothing
Its a Samsung 983 DCT NVMe 1.92 TB capacity. Sequential write speeds of 1900 MB/s, random reads of 540k IOPs, and random writes of 50k IOPs.
1 Like
7 seconds seems a bit more realistic than 1 second but still, crazy fast for 2.2 GB of data.
What tool did you use to perform the search? pdfgrep?
Wow, a lot of people sticking with EXT4? I know itâs a classic and stable as a rockâŚbut itâs dumb as one too. Even on my production servers I use XFS over EXT4. 
Iâm using BTRFS on my laptop though.
1 Like