Permanently Deleted
Trim support is standard. Any kernel released in the past 15 years or so will have trim support built in. So that’s not something you should worry about.
How trimming is triggered is another matter, and is distro dependent. On Arch and Debian at least there is a weekly systemd timer that runs the fstrim command on all trimmable filesystems. You can check it if’s enabled with: systemctl list-unit-files fstrim.timer. I can’t tell how other distributions handle that. On Debian derived ones, I imagine it’s similar, on something like Slackware, which is systemd-less and more hands-off in its approach, you may have to schedule fstrim yourself, or run it manually occasionally.
There is also the discard mount option that you can add in /etc/fstab, which enables automatic synchronous trimming every time blocks are deleted, but its use is discouraged because it carries a performance penalty.
Hope that answers your question.
If I may, what’s trim?
I have never read much about trim before. Now I’m curious about something: if an ssd was trimmed, is all deleted data lost? Is filling an ssd with random data unnecessary if we want so safely delete something?
What exactly happens when you issue a TRIM depends on the SSD and how much contiguous data was trimmed. Some drives guarantee TRIM-to-zero, but there’s still no guarantee that the data is actually erased (it could just marked as inaccessible to be erased later). In general you should think of it more as a hint to the drive that these bytes are no longer needed, and that the drive firmware can do whatever it likes with that information to improve its wear-levelling ability.
Filling an SSD with random data isn’t even guaranteed to securely erase everything, as most SSDs are overprovisioned (they have more flash cells than the drive’s reported capacity, used for wear leveling and the likes). even if you overwrite the whole drive with random bytes, there’s a pretty good chance that a number of sectors won’t be overwritten, and the random bytes would end up going to a previously unused sector.
Nowadays, if you want to wipe a drive (be it solid state or spinning rust), you should probably be using secure erase - it’s likely to be much faster than simply overwriting everything, and it’s actually guaranteed to make all the data irrecoverable.
There are some differences between distros as to whether TRIM is enabled by default or not (I’ve read Ubuntu enables it by default, but Debian does not). That said, depending on what file-system your ssd is formatted with it may be enabled by default at that level. The most-often recommended file-systems for SSDs are Btrfs and F2FS, both of which support and enable TRIM by default (as of Linux 6.2 for Btrfs, so if you are running an older kernel version you might need to manually enable it). I think most distro installers support using Btrfs as the main file-system, but F2FS is a bit more hit and miss I think. Safest bet would be to investigate once you settle on a distro, but support should be pretty standard, even if it’s not enabled by default.
This is a bit of misinformation. There is no evidence other filesystems have any downsides on an SSD. Use the default choice of your distribution. Roughly nobody uses F2FS on desktops. EXT4 is entirely reasonable and supports TRIM.
XFS supports trim too, and is arguably the highest performing filesystem for NVMEs in terms of multi-theaded use-cases. BTRFs is among the slowest filesystems for NVMEs both in IOPS and sequential metrics.
not sure about manual but on ArchLinux and NixOS, TRIM can be automatically handled with BTRFS options:discard=async:
- Enables discarding of freed file blocks in large chunks before queuing for TRIM.
not sure if this helps but I’ll be open sourcing my NixOS build and configuration.nix files in a bit(after school schedule stablizes)
