In my experience once you fill an SSD it takes a long time for the performance to recover even after clearing it out, but I don't know why.
I partition my SSDs to make sure in never fill them.
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
In my experience once you fill an SSD it takes a long time for the performance to recover even after clearing it out, but I don't know why.
I partition my SSDs to make sure in never fill them.
Usually trim runs on a cycle, either invoked by the OS or triggered by the drive. The time between trim and you deleting the files may see a performance hit as the firmware has to check if the blocks are in use, rather than knowing beforehand if they are.
alright edit: I have a Flatpak issue, not an SSD issue. does anyone have any thoughts? this could be due to the new linux mint update. my pc is a samsung galaxy s2 (750XED P13CFG)
the linux mint discussion forum has a post about my model not being great but last update my system worked just fine. i actually think having a full ssd broke flatpak. otherwise ive hit a horrible regression issue https://github.com/orgs/linuxmint/discussions/277
Backup and install a fresh Linux Mint.
It still sounds to me like something's up with the disk. Can't think of any solutions to suggest but I would run a SMART health check on it:
sudo apt install smartmontools
sudo smartctl -a /dev/sda
If you prefer a graphical tool, you can do the same thing with GNOME Disks, which also has options for disk benchmarking.
In the resulting report, the overall health state should be "PASSED", the "Type" column should show "Pre-fail" and "Old age" values, and the "Media-Wearout-Indicator" should be close to 100. If the overall health state is "FAILED", then you will want to back up your files immediately and consider getting a new SSD.
What filesystem are you using? Is it encrypted?
Could you run a benchmark to verify if reads and writes are both affected? KDiskMark is like crystaldiskmark or Gnome Disks has a built in benchmark.
not encyrpted. i tried running a write test in gnome disks but i get 'error unmounting /dev/nvme0n1p2: target is busy (udisks-error-quark, 14)
What do you mean with "Deleted half of my storage"?
How did you do that? Did you just go into your file manager and deleted some photos, or did you remove partitions and stuff outside of /home/?
You know of the "linuxatemyram.com"-site, do you? Did you try to "optimize" the RAM consumption or other performance tweaks? It sounds like you "don't have enough RAM" and then Linux tries to use the swap space, pulling stuff from your SSD.
Did you install Mint freshly onto the new SSD? Did you use the recommended partioning-layout (regarding swap space)?
I hate to say it, but did you try to reinstall your OS? Maybe that might help...
i deleted half of the data on the ssd (no it's not in the trash folder.) i deleted timeshift files and unused apps. how do i optimize ram consumption and get 'other performancw tweaks'. i shouldnt be running out of ram if nothing is loaded and i just booted up? yeah i installed mint on to the ssd when i got it. i dont dual boot so do i need to partition? no i have not reinstalled linux but i might
i deleted half of the data on the ssd (no it's not in the trash folder.) i deleted timeshift files and unused apps.
Can you name a few examples? Apps usually don't need much data, and timeshift backups aren't accumulative, so only the first one is big, and the following ones are just a few MBs big.
Why not store them on an external drive? That would be the best method anyway, in case you can't access your PC.
how do i optimize ram consumption and get 'other performancw tweaks'. i shouldnt be running out of ram if nothing is loaded and i just booted up?
Easy. You don't :)
Linux is already very optimized ootb, and the only thing you can install for example is TLP, a battery life prolonger for better runtime on laptops.
Other than that, don't. And take a look at the link, everything gets explained very well and simple there.
i dont dual boot so do i need to partition?
If you have to ask this, it should be fine. The default layout on Mint is good as is.
no i have not reinstalled linux but i might
Remember to backup your data!!!
If you haven't made many customisations, every file should be restored easily. Might help, but keep an eye on your actions.
Don't do stupid things and maybe consider immutable distros, like Fedora Silverblue, since you can't mess up anything on them.
read the edited post! apparently somethings wrong with the gtk3 module, im only having slow boots for flatpaks!!
How long ago did you delete everything?
SSD's dont work like old HD's depending on the generation of tech it might be storing multiple values per cell which means when you "filled" the SSD you put a charge into every single storage cell on the drive.
Garbage collection and TRIM will slowly over time clear out all the cells flagged as deleted but if one bit is still valid in a cell that was holding 3-4 other bits it cant overwrite that, or relocate it.
That means that your files/videos and such stay fragmented and may never get put back together sequentially or in a way that the controller can optimize again for speed.
The only fix, may be running a factory wipe from the Drive MFG's tool set, that should fully blank each cell and let you re-install and make it feel fresh again.
Be warned though, you have already done a full drive write once at least, this would be another. You can expect some dead cells and while there is over provisioning that should provide replacements you could see a loss in usable space sooner than later.
i deleted everything ywsterday, and i trimmed today. i was unaware of the dead cell issue. is there a way to disk defragment an ssd?
in theory time, it should slowly rewrite everything to consolidate it. If you dont have time, then factory format and reinstall.
I had this issue as well, but my file system was broken when i was trashing a OS, I did not know it was xdg-desktop-portal-gtk or xdg-desktop-portal-gnome I think it was Debian with cinnamon or maybe LMDE.
Flatpak on Arch? Is what you want not in the AUR?
no flarpak on linux vut apparently this imapcts flatpak on arch as well
I'm sorry, I found your response confusing. Arch is a Linux distro, I know flatpak is available for it. If there's a bug with flatpak, I would expect it to be pretty much the same across most GNU based Linux systems. My question, however, was why use flatpak on Arch Linux at all, as the AUR has pretty much everything including the kitchen sink... unless you are developing flatpaks, I guess, in which then it would make sense to me.
You don't owe me an explanation, it just sounded odd to me to be needing flatpak when there was AUR, was all.
I had this problem with flatpaks, I changed the dbus implementation to dbus-broker (in endeavouros) and it fixed the issue. It may be the same problem.
how do yoy do that
I installed dbus-broker and the package manager checked the dependencies and removed the unnecessary stuff. After that I applied the dbus-broker services:
systemctl enable dbus-broker.service
sudo systemctl --global enable dbus-broker.service
And then restarted.
Idk if it might break things in mint, so I would be cautious.
by any chance does this have to do with gtk3?
Yes, I remember reading about a gtk thing that interacts with flatpak, they said it should not give this error in April, but it seems to still be happening, idk.
Edit: I just saw that you deleted the gtk portal and it worked! So no need to install another dbus daemon.