Fedora 40 SIlverblue becomes unresponsive when something is writing on disk

Because of updates in the background or files copying, other applications tend to become unresponsive, forcing me to quit them. This issue occurs randomly, and I was hoping it would be resolved in version 40, but it has not been fixed.

let’s have a look at disk IO, CPU usage, and RAM while this is happening…

Maybe you could start by disabling automatic updates as those happen in the background and may create a lot of disk IO.

Still this is not normal, it happens all the time even copying files and I have an ssd, what can I do to find out why this is happening?

Hi Flo, can you suggest a command to test?

gnome-system-monitor is a good start to get an overview of your system performance

I would open a terminal and type top in it leaving it going while I was using my PC as normal. Then let top show you what’s using the resources during the “slow” times. Gnome system monitor will do that as well with added overhead.

Everything becomes urresponsive and my web browser advise me to force quit, the resource usage It’s always normal, this is an example when I was downloading something.

Just in case someone faces the same issue It seems that the problem was my disk being QLC instead of TLC and the use of BTRFS, it seems those disks perform poorly with BTRFS specially if there is not much space available.

I can’t confirm this 100% but that’s what I found on the internet and my laptop with a TLC disk doesn’t have this issue with BTRFS.

This might be related to one of the filesystem slowdowns I posted at I need your best performance tips! - #12 by garrett a while ago.

Specifically: Having encrypted partitions (using LUKS) prevents your SSD from trimming properly on Fedora Silverblue. (I’m not sure if this affects traditional package based Fedora too, or just Atomic.)

Over time, every Fedora Atomic installation will hit this bug and get slower and slower when IO happens.

The solution I found was to run this:

sudo cryptsetup --allow-discards --persistent refresh /dev/mapper/luks*

I’ve seen other people mention there are other ways to do this, but this command worked for me, and I’ve tested it on a few Silverblue installs over the past couple years.

You can test to see if you’re affected or not by running sudo fstrim -va — this will take a while and show you filesystems more than just /boot/efi and /boot if it’s working. (It should show / for example.) If you don’t see /, then you probably need to run the command above (or some other command to enable discards).

2 Likes

Thanks Garret :grinning:, I forgot to mention that my disk is encrypted, I will test if the problem is gone now and report in the comming days:

linuxkernel@linuxkernel-mini:~$ sudo fstrim -va

[sudo] password for linuxkernel:

/boot/efi: 587.2 MiB (615768064 bytes) trimmed on /dev/nvme0n1p1
/boot: 820.5 MiB (860340224 bytes) trimmed on /dev/nvme0n1p2

linuxkernel@linuxkernel-mini:~$ sudo cryptsetup --allow-discards --persistent refresh /dev/mapper/luks*

Enter passphrase for /dev/nvme0n1p3:
No key available with this passphrase.
Enter passphrase for /dev/nvme0n1p3:

linuxkernel@linuxkernel-mini:~$ sudo fstrim -va

/boot/efi: 587.2 MiB (615768064 bytes) trimmed on /dev/nvme0n1p1
/boot: 0 B (0 bytes) trimmed on /dev/nvme0n1p2
/: 104.6 GiB (112335757312 bytes) trimmed on /dev/mapper/luks-b2402843-66ea-424c-8030-4aeeeed76b62

I confirm, the problem is gone, thank you!!