KDE burn my SSD

Community
1

Dear KDE community, I don’t want to use KDE anymore. The fact is that I’ve been using GNU/Linux for 1.5 years now. I chose Debian 12 KDE because of its beautiful design and functionality. But 4 days ago I got a message like the one in the screenshot that my SSD is going to die. -I didn’t know why, but I felt very uneasy.
The SSD drive is Samsung 970 Evo Plus 500GB M.2 PCIe 3.0 x4 V-NAND 3-bit MLC, I have had it since the summer of 2019, but before that it had only Windows on it. I also checked the status of CrystalDisk, Victoria357, etc. in various programs. And the condition was good.

But after switching to Linux, I installed a dual-boot (Windows 10 + Debian 12 KDE), and everything was fine until the last few days.
I have backed up important files, and I am waiting for the death of my SSD. When I checked the SSD status in Samsung Magician on Windows, I saw that the SSD has written more than 750 TB , how is this possible?
I was at a loss and didn’t know what to do, except for a quick backup. Today I took some measurements, I opened the Resourses program on Linux, saw that the disk was idle (after starting the system, and without any programs, it recorded 9.4 GB in 10 minutes), and in a simple browser opening, all 31.85 GB.
So I opened the task manager on Windows 10 and saw that the disk was not transferring or interacting with data,

After all the rescue, chatGPT, forums, etc. I came across this thread

/r/SteamDeck/comments/11y9s4s/warning_baloo_can_potentially_damage_your_ssd/?chainedPosts=t3_ah2aww

And what is the program from KDE Baloo

Baloo is a file indexing and search framework used in the KDE Plasma desktop environment. It scans and indexes files on your system to enable fast file searches, including searching for file content and metadata. While useful for organizing and locating files quickly, Baloo can sometimes consume significant system resources, especially on devices with limited hardware or SSDs, leading users to disable it to conserve performance or avoid excessive disk writes.

After I watched this thread, I was shocked, all these 1.5 years a program with KDE has been stupidly eating up my disk capacity, it’s worse than parasitism, AND THIS PROGRAM WAS ON BY DEFAULT, AND ANYONE, new or experienced, would not even know about it.
Because it was enabled, a 1-2 hour session in Debian cost me 1 TB of storage on my SSD, just think, no download, just scrolling through the browser and watching

And that’s not all, with the help of ChatGPT, I was able to disable baloo (in the reddit thread it is shown more clearly)

I used
sudo balooctl stop
sudo balooctl disable

But then I restarted and the result was the same. But then I still had to change the settings in ~/.config/baloofilerc
so that it would not start at all.

After that, SSD writing in idle and in operation became normal, and without exaggeration, now I’m writing this post and I have a total write of 8.46 GB / total read of 4.20 GB in two hours, and this is not even the figures for 10 minutes in idle mode with nothing!

And this is not the end of the story, because there is another “indexing” setting, and it is also enabled by default, and yes, it should also be turned off.

I’m just in shock from KDE, from love to hate = one useless SSD

I also want to add that I have a laptop with Devuan 5 KDE, and guess what, the same thing. Everything is enabled by default…

Baloo could eat from 100 to 250 MB in a couple of seconds, and so on and so forth…

Thanks KDE, give me back my money for the SSD.

Default not full day session i guess, with no any download or smth

Please, everyone who has read this post, REVIEW AND DISABLE WHAT I HAVE WRITTEN

1 Like
2

1 TB of your 500GB drive is used after 1-2 hours? How is this even possible.

After 18 months, KDE 5 (TuxedoOS) for one year and KDE 6 (Arch) for the rest on this laptop the SSD “SMART”-Status shows 4472 Power on hours with (only) nearly 6TB of “Data Units Written” and everything okay. And I have even longer used KDE (Kubuntu) before without experiencing such a issue.
A iotop -a for 10 minutes, opening the browser, playing a YT video in the background while only listening doing a random google search, opening and scrolling down the results faster than I can actually read continuously, had 46M total written mostly by Firefox (as I would have expected). A systemd “baloo_file” process ,I had spotted, had literary zero disk IO in that time period.

Baloo misconfigured in your case? Don’t know, never even touched Baloo (knowingly) as I never heard of it specifically before.

3

I understand your frustration and I agree KDE might have a bit too many services on by default.

However, I don’t see such a horrific disk usage on any of my machines with KDE. Plus, Windows and MacOS also have indexing on by default (that, whether we like this or not, might be what “average” user expects), and I’m sure you could find some Internet threads with “Windows ruined my SSD”, too. Lots of users have lots of different situations.

So in addition to just telling everybody that, assumingly, Baloo is the reason, it would be great if you could help others (KDE developers, too) by sharing more details of your setup (especially valuable because other users don’t experience this).

Like for example:
Have you tried looking at the disk usage history chart in KDE System Monitor with Baloo off and on? This is what I see:

Screenshot_20250109_104257
Screenshot_20250109_104257575×302 18.8 KB

I would assume that with Baloo off, you’d see something similar, but with Baloo on, you’d see a steady, very high line. Is that so? If yes, do you get excessive writes or reads there?

Next, if Baloo really reads or writes something A LOT, what is it on your disk that it gets so “interested” in? Do you have any folders with lots of small files? Could you try temporarily erasing them and checking if high disk usage stops?

I’m sure some knowledgeable users could even share some command line snippets to track which specific files are getting read/written, and by what process.

4 Likes
4

baloo has failed like that for me, and others; fortunately I noticed within a day that something was writing 60-70 MB/s continuously. I only noticed because of another failure mode of baloo, where its index ballooned to tens of GB, and caused my backups to take longer, so I was keeping an eye on it. For both types of failures the problem was in the index, not possibly weird data; if I stopped baloo, purged, and restarted it, it completed indexing in a reasonable time and with reasonably sized index; typically within a few weeks baloo would misbehave again.

Like the OP I was disappointed that KDE shipped in a form that could cause a hardware failure. Some sanity checking in baloo would surely be a good idea.

IMO the opaque nature of baloo is bad design. I’ve seen reports that this has improved, but of course I haven’t let it run since the above incident.

5

I disabled it after discovering a 20+gb index file and will never allow it on my system again. The locate and find/grep will get me any files I want without that junk taking up all of my space for an index especially when the files on that partition only take up 18G at the moment.

zeus@9600k:~$ df -h |grep home
/dev/nvme1n1p3   79G   18G   61G  23% /home/zeus
6

I on the other hand have been using it for a long time now with no issue, even adding extra location for documents to be indexed. I have not seen/noticed the giant index file in some time myself.

Now, even though I have been using it for pretty much as long as it has existed, I will definitely say it was a rough go for a very long time. I have noticed few issues myself in a few years. I do see some people still have problems, and I know that my experience may not be indicative of the norm, just as a bad experience also may not be.

But this bug was…interesting. I never actually noticed it at the time, as had a fairly beefy i5 13th gen system with multiple nvme drives and SATA SSDs at the time. That nvme drive now sits in my much lower spec 7th gen i5, still as my main OS drive.

I would suggest that using it on flash-style drives, such as EMMC storage used on Chromebooks and the cheapest Steam Deck may not be a good thing, longevity wise. Definitely not good if running an OS on an sdcard or usb stick (low end Chromebook hardware). I always disable indexing on EMMC and usb sticks if using those for OS drives, mostly because the speed of these already-slow storage devices does slow when indexing does take place.

But the notion of burning up an SSD from the write rates is quite a bit outdated. Imnsho, of course.

My index is 1.3Gb on a $HOME of 280Gb plus nearly a Gb of docs on a different drive, indexing names and content. The total number of files changes up and down regularly. It is on the low end at the moment.

I do heavily use the content search, especially for PDF and different office type files. I also only use SSDs, mostly nvme on my non-NAS systems. I imagine even ‘slow’ indexing would affect a spinny HDD performance too much still if used as an OS drive.

1 Like
7

My 512 GB SSD has been in use since 2019, and for the last 3 years I have been using KDE Plasma on Manjaro and Arch Linux later. Total host writes is 57TB, although I believe that a big portion of this is done by myself, I move data to and from SSD a lot, the fresh couple of terabytes alone should be dedicated to stalker 2 updates (yes it’s what games do nowadays). However, in my case I never encountered bloated baloo index so far, nor noticed constant writing to SSD. My total storage is around 4.5TB, almost fully used, and baloo index never exceeded few hundreds of megabytes. It’s just my personal experience. I am not denying that horrible things can happen.

8

Having a link to another drive in your personal home directory could cause indexing spiral out of control as well.
Never tried on Linux but on Windows I had some fun with NTFS hardlinks in the past starting from some tools reporting something like “700 of 500 used”, which looks a awful lot like what the OP tried to tell, to being able to create infinite subdirectories that could catch some AV Software on scheduled scans to scan the same files for eternity and/or potentially crash that AV. A Fun time that was. But that was on Windows keep in mind.

1 Like