My Experience: BTRFS (no Baloo, KDE Plasma)

Thanks to everybody in this wonderful community and in both threads Indexed Search with BTRFS (not Baloo) and Welcome App Installation!

To summarize, Baloo had lots of problems with BTRFS, finally, (above two threads) I made a fresh install with BTRFS.

Just to share my experience hoping it will be of benefit:

  • After installation (empty /home) I created a text “.txt” file with a few words in it. Edited, rebooted, edited, rebooted,… etc. As expected searching for a specific word I got in Dolphin TWO results of the same file!
    So, I assume a snapshot was taken and Baloo reindexed the snapshot. I didn’t install or try anything snapper or any other snapshotting (TimeShift). Are snapshots taken by default through BTRFS itself? Can someone please explain a bit how this happened though I installed nothing or issued any snapshotting commands?
  • So, I disabled Baloo and purged the index (using sudo to make it permanent). Reboot, edit… move… etc… to test… Everything is working perfect.
  • I downloaded a PDF book, searching for a word or phrase through Dolphin (content),- though I can select/copy text from the PDF, - not found! This raises a question, content search working fine with .txt file, but not PDF. I read somewhere there is an app/command/service that makes the system treat PDF as a text file! Did I get it right? Couldn’t find this again. Any clue?

I will now install pCloud and Koofr and see how it goes.

I will update you to share experience.

Just thinking, maybe a PDF reader that can “follow” PDFs in /home folder and subfolders can search all file contents?

EndeavourOS University is open 24/7 :smiling_face_with_three_hearts: :tada:

1 Like

Right click on the file and select open with and choose your pdf reader

Thanks for caring to help @smokey
Actually just clicking the file opens it in Okular.

I am trying to find a way to let KDE/Dolphin search PDF content as it does with .txt and .html. I like it is being searched without the need to add an indexing software like Recoll (or Baloo which I disabled because of its problems with BTRFS)

Thank you!

Just use pdfgrep. You’re making your life unnecessarily complicated with all this indexing nonsense.

This is what I am trying to do. I believe there is perhaps a service that makes KDE treat PDFs as it did with .txt and .html files. I always tend not to install any software if possible! I love KISS!

For now I am checking Foxit Reader!
But hopefully I can find a way to let KDE do PDF as mentioned above.

For example, if I want to search for the keyword “poop” in my collection of e-books on politics, I simply run this command:

pdfgrep -r 'poop' ~/Documents/ebooks/Politics/

I have about 1.5 GiB of pdfs in that branch of the filesystem tree, which is on a fairly slow HDD. It takes about a minute to go through them all. On an SSD, it’s a matter of seconds (and it’s a good idea to keep the files you access often on an SSD, of course). No indexing nonsense.

No, no, no… That is 𝖆𝖇𝖘𝖔𝖑𝖚𝖙𝖊𝖑𝖞 𝖕𝖗𝖔𝖕𝖗𝖎𝖊𝖙𝖆𝖗𝖞! I’m afraid that just won’t do.

1 Like

I believe -at least for me- through a GUI is more convenient. When I search I am most of the time researching, so I need an easy way to find multiple files, open the files I need, open others…

After I downloaded all my files (lots in text .txt) I find searching their content is perfectly fast for me without any indexer installed or running)
I recently replaced my HDD with a SSD!
My understanding that BTRFS makes it even faster (being compressed) (Please correct me if I am wrong)

I just hope to find this service for PDF (again I might be wrong! as usual :rofl:)

It might just be prejudice. Try it for a few months with the terminal. You can’t know what is more convenient if you haven’t tried any alternatives.

I’m sure there is some GUI front end for programs like grep and pdfgrep, but such a thing really cripples their full potential.

A quick search discovered this:

Looks like utter rubbish to me, to be honest.

I’m not aware of anything like that existing. KDE’s search functionality is based on Balloo, and it sucks.

OK. I will try now. Hopefully it works. Maybe I will make a script for convenience (hopefully I will have enough IQ to do a simple script)

Honestly I loved Baloo and had no problem with it (on EXT4). It was one of the main reasons I been on KDE.

But with BTRFS and all the problems of Baloo not playing well with BTRFS, and because I believe BTRFS is the right way to go, it is the future of FS, so I made all this noise about me installing EOS on BTRFS.

I think you’re wrong about that. But time will tell.

For the time being, ext4 is a perfectly fine filesystem for 99% of users (those who do not really need the fancy features of Btrfs).

1 Like

recoll is a solution for @limotux who has thousands of books. Without indexing file is too slow for him using his 32bit computer.

On Arch… Yeah, I’m going to press X to doubt.

Besides, bottleneck to searching speed is the drive reading speed, not the width of memory addresses.

But yes, Recoll/Xapian is a popular option, if you insist on indexing.

Well, the main reason is feeling a bit more secure that I can boot from Grub to a previous working state just in case. Though it can be done through Timeshift under EXT4, but seems to be lot of work to recover if system is unbootable.

And another reason (though might sound stupid) it is my personality! Yes! I tried BTRFS before (maybe September 2021 - you can search my old posts) and it gave me lots of problems. So, for my personality, this is a challenge I will never feel comfortable or settled unless I overcome it!

I assure you if I confronted Godzilla or the Incredible Hulk, I will never give up till I control them or I die! (Sounds stupid I know, especially I know there are bugs in BTRFS and EXT4 is more stable and mature.)

(@dalto yesterday said my VM 32 bit perhaps because of BIOS settings)
I admit it this machine is quiet old (since 2013) but it is 64bit:

  Host: lenovo Kernel: 5.18.15-arch1-1 arch: x86_64 bits: 64 compiler: gcc
    v: 12.1.0 Desktop: KDE Plasma v: 5.25.3 tk: Qt v: 5.15.5 wm: kwin_x11 vt: 1
    dm: SDDM Distro: EndeavourOS base: Arch Linux
  Type: Laptop System: LENOVO product: 20157 v: Lenovo G580
    serial: <superuser required> Chassis: type: 10 v: Lenovo G580
    serial: <superuser required>
  Mobo: LENOVO model: Lenovo G580 serial: <superuser required> UEFI: LENOVO
    v: 62CN97WW date: 07/12/2013
  Info: dual core model: Intel Core i5-3210M bits: 64 type: MT MCP
    smt: enabled arch: Ivy Bridge rev: 9 cache: L1: 128 KiB L2: 512 KiB
    L3: 3 MiB
  Speed (MHz): avg: 1253 high: 1311 min/max: 1200/3100 cores: 1: 1307
    2: 1197 3: 1197 4: 1311 bogomips: 19962

and I have an SSD (not huge but OK)

  Local Storage: total: 232.89 GiB used: 9.33 GiB (4.0%)
  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
  ID-1: / size: 232.59 GiB used: 7.43 GiB (3.2%) fs: btrfs dev: /dev/sda2
  ID-2: /boot/efi size: 299.4 MiB used: 608 KiB (0.2%) fs: vfat
    dev: /dev/sda1
  ID-3: /home size: 232.59 GiB used: 7.43 GiB (3.2%) fs: btrfs
    dev: /dev/sda2
  ID-4: /var/log size: 232.59 GiB used: 7.43 GiB (3.2%) fs: btrfs
    dev: /dev/sda2
  Alert: No swap data was found.

I will keep trying and I will see what was suggested before. I just installed

 yay -Syu pdfgrep

to try

1 Like

Oh I see.

You know what! I had HP PAVILION X360 (3 years old now with Windoze), I gave it to my family to do their work on. But when it was fresh out of the box was not like EOS on this 10 y/o machine!)

And I am challenging myself, hopefully to keep this machine working on Linux till I die… maybe they can sell it as a historic monument or as a live Dinosaurs by auction for a fortune!

[limo@lenovo ~]$ pdfgrep -r 'economic' /home/limo/Koofr/
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
Aborted (core dumped)
[limo@lenovo ~]$ 

Again, Why me!

Your locale is incorrectly set up.

Can I see the output of the following commands



grep -v '^#' /etc/locale.gen 


You should really open a new thread for this, post the output of those commands there, not in this thread, which is not about troubleshooting pdfgrep.

Yes I just fixed it thanks to @Zesko earlier here Inxi -Fxxx Strange Locale Settings - #29 by Zesko

Then tried again

pdfgrep -r 'economic' /home/limo/Koofr/

It worked! But it kept “spitting” and scrolling 100s of lines from 100s of files

I don’t know how can this be practical for my use case! With all my due respect. I am just discussing and trying to learn more.
Hopefully I can do without indexing as it is doing with .txt and html.

Yeah, if you search for the word “the”, you’re going to get even more results. :man_facepalming:

Inxi -Fxxx Strange Locale Settings - #29 by Zesko

Not a good solution (as @petsam correctly pointed out that topic). You’re overriding all your locale settings in your shell, effectively forcing American English for all programs that run in your terminal. It’s much better to set up the locale properly, system-wide. But you do you, this is getting a bit tiresome.

1 Like