this post was submitted on 03 Sep 2023
41 points (97.7% liked)

Linux

48332 readers
958 users here now

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.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
41
Linux SSD TRIM support in 2023 (lemmy.world)
submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/[email protected]
22 comments fedilink hide all child comments
 

This might be a really stupid noob question, but I am looking to move to Linux from Windows/Mac, and am about to install an SSD into my very old test machine for Linux distros.

You might have seen my recent post asking for recommends: it has the hardware specs of my test box, and I've updated it with the list of distros I intend to try.

My test box still has a working HDD in it, so no action is required immediately.

But my question is: once I decide on a distro and start moving machines over to Linux, what kind of manual care do I have to put in to maintain my SSD drives, if any?

For each box with a SSD drive and Linux as the OS, do I need to do TRIM manually, do I need to turn it on for a "set and forget" type scenario, or are recent and regularly upgraded distros able to spot a SSD and do the necessary without my intervention?

I guess what I'm really asking is: is SSD TRIM support pretty much standard now across distros, or is it something I need to investigate individually for each distro I install?

I recognize I may just need to ask this again once I settle on a distro, but since I'm trying so many -- and may fully install more than one -- I thought I'd get a jump on it.

EDITED TO ADD: Many thanks to all who took the time to answer. Now I know exactly what to read up on, and if necessary, look up how to do manually for whatever distro(s) I settle on. I -really- appreciate the help. Thank you!

top 22 comments
sorted by: hot top controversial new old
[–] [email protected] 50 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] [email protected] 9 points 1 year ago

Yes, this helps tremendously. Thank you so much for taking the time to write out not just the info, but all the terminal instructions for this noob. Much appreciated!

[–] [email protected] 7 points 1 year ago

the Arch wiki has some info. Not too sure but i think enabling the systemd timer is enough.

[–] [email protected] 5 points 1 year ago (1 children)

If I may, what's trim?

[–] [email protected] 12 points 1 year ago* (last edited 1 year ago) (1 children)

Excellent question, and for people who have SSDs it's worth knowing the answer.

Very simply, SSDs store data differently than HDDs, and when a file is removed, sectors on SSDs have to be explicitly cleared instead of simply waiting to be overwritten like on HDDs. Not doing so on a regular basis decreases the lifespan of the SSD. Crucial (a SSD manufacturer) explains it here much better than I can:

https://www.crucial.com/articles/about-ssd/what-is-trim

[–] pm_me_some_serotonin 2 points 1 year ago (2 children)

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?

[–] [email protected] 3 points 1 year ago (1 children)

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.

[–] pm_me_some_serotonin 1 points 1 year ago

Thank you for your response, I didn't know about secure erase. Looks like my knowledge is a bit outdated.

[–] [email protected] 0 points 1 year ago* (last edited 7 months ago)

deleted by creator

[–] [email protected] 4 points 1 year ago* (last edited 1 year ago)

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)

[–] [email protected] 4 points 1 year ago (1 children)

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.

[–] [email protected] 5 points 1 year ago (1 children)

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).

This is great to know on multiple levels because in Windows it is triggered from the OS, I think as a weekly task, and NTFS has little to do with it as far as I know.

It's also good to know that support is pretty standard now, as a lot of what I found online was just old and the rest assumed I'd already be familiar with it. Bad assumption, lol.

I don't know enough to have a preference one way or another for a specific file system, so I can just start with Btrfs and go forward with that. I can also read up on Btrfs further on its own, which I now know to do.

Safest bet would be to investigate once you settle on a distro

Absolutely. But this gets me started, and pointed in the right direction. Many thanks.

[–] [email protected] 7 points 1 year ago* (last edited 1 year ago) (2 children)

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.

[–] [email protected] 5 points 1 year ago (1 children)

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.

[–] [email protected] 4 points 1 year ago

Indeed. BTRFS is a different class of filesystem in terms of features too. Their merits are more than “SSD support”.

[–] [email protected] 0 points 1 year ago

Ext4 seems to be the default across the distros I've looked at so if I can just run with that, all the better. Thank you for pointing this out, much appreciated.

[–] [email protected] 2 points 1 year ago* (last edited 1 year ago) (1 children)

Edited

lsblk --discard to check support and non zero DISC returns mean TRIM supported. ~~And then you need to add discard options to supported partitions in /etc/fstab.~~ Then enable fstrim.timer with systemctl. And it will automatically run weekly. You can edit the run frequency by editing the fstrim.timer file.

This is what I have done from reading Arch wiki. https://wiki.archlinux.org/title/Solid_state_drive#TRIM

[–] [email protected] 8 points 1 year ago (1 children)

You typically use either discard or the fstrim.timer, but not both at the same time.

Using the discard option means that trims are being done on the fly every time blocks are deleted, using fstrim.timer means that trims are being done periodically. The former carries a performance penalty, so it's usually not recommended unless you need it (for example, if you regularly do huge amounts of writes and deletes on this drive).

[–] [email protected] 2 points 1 year ago

Thanks for this. I got confused writhing this as I used discard on my previous install.

[–] [email protected] 2 points 1 year ago (1 children)

Can't answer your question since it's not something I ever thought about but I recently, within the last 2 weeks, started the same thing. I tried Mint and EndeavorOS so far and honestly I probably won't leave EndeavorOS again. I installed it first. Confused the fuck out of myself because years ago I use Ubuntu so I had that like hard coded in me and couldn't get my head around arch. After playing with Mint for a week or so I'm back on EndeavorOS and I love it. I really really want to switch my main PC over but I have a Plex server and audio book shelf server running there as well as atleast 1 game that playing on Linux just isn't possible since Bungie will ban you for running destiny 2 on Linux.

[–] [email protected] 1 points 1 year ago (1 children)

EndeavorOS

I'll add that to the list of distros I want to try, I hadn't seen it before but it does run on minimal hardware. I like that it's built on Arch because Arch itself is a good OS, but intimidating for a noob, lol. According to Distrowatch.com it's near the top of their page hits so it must be popular. Thanks for the recommend!

Bungie will ban you for running destiny 2 on Linux.

That is so bizarre to me. According to this article, Destiny 2 was already playable on Linux when it was officially ported to Google Stadia, and no one, not even Bungie, can explain why they won't support it on Linux or Steam Deck, much less ban a player for trying. That's crazy.

[–] [email protected] 2 points 1 year ago

would consider myself very much a noob and I'm bumbling my way through it. Just kinda worked my way through it and pretty sure I broke my mint install a bit before hopping to EndeavorOS and will probably break this one before I'm done as well.

That is so bizarre to me. According to this article, Destiny 2 was already playable on Linux when it was officially ported to Google Stadia, and no one, not even Bungie, can explain why they won't support it on Linux or Steam Deck, much less ban a player for trying. That's crazy.

Yeah I have no idea either. From what I've seen online it's something to do with the anti cheat battleye but that runs on Linux so it's basically just them telling the Linux community to go pound sand.