Thank you for posting your experiences regarding your system slow downs. Hopefully with enough user feedback we can pinpoint the steps we need to take to help Garuda run more smoothly on all systems.
Perhaps running services to do regular maintence tasks on a schedule might be the way to go. My feeling is this can't be an extremely common occurance or I think my more users would be reporting these slowdowns.
I've only gone through several short periods where my system was affected, but the slowdowns were drastic. In my mind there must be a commonality in the cases where these slowdowns happen after either a very large update or a snapshot restore.
My thinking although I have no real evidence is that this affects users with small memory based storage devices more so than large platter drives for their system OS drive.
I only use a small 120 GB SSD drive as my system drive and I use large 10 TB drives for storage. While the small SSD drives worked well with ext4, I'm starting to think they may be too cramped for more than 3 or so btrfs snapshots.
I also use a separate home partition from years of ext4 habit. I am now starting to think this is only exacerbating this issue as the empty space from home would help with reducing the percentage of flushed data accumulating on the root partition. I could change this manually of course, but I think I will leave changing my partition structures until my next full install. I plan to add a dedicated Ext2 boot partition to help grub save my default kernel boot choice. So, I think some structural changes may help with these slowdown issues as well. Again, just a suspicion.
I could be wrong, but I'm thinking the smaller drives while they are fine as far as space they will have a far higher percentage of redundant flushed data when large blocks (such as snapshots) are flushed.
I have no idea if my suspicion is correct, but I'm thinking that if you are using a small drive, (or small partition possibly?) for your OS then you may need to perform system trim and balance operations far more frequently than the average user.
As I stated this is only my suspicion at this point, but I will be adjusting my maintenance schedule to see if the adjustments help prevent this in the future.
Edit: also in the back of my mind I have a sneaking suspicion that keeping many kernels installed also makes this situation worse. I have no proof, but as I was testing up to a half dozen different kernels at a time, that itself was probably a big factor in increasing flushed data from so many kernel updates taking place regularly. I assume most users don't run more than a couple of kernels, but I need to know good alternates to recommend to users having issues, so I usually have a bunch installed. While I have no evidence on this subject, I think keeping more than 2 kernels installed at a time could be a contributing factor with this issue.