From: Michael <confabulate@kintzios.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] What are common SSDs does and don'ts.
Date: Sat, 22 Mar 2025 21:37:37 +0000 [thread overview]
Message-ID: <3275233.5fSG56mABF@rogueboard> (raw)
In-Reply-To: <d8ec9ec1-1622-d0d5-4120-b811b6629292@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4097 bytes --]
On Saturday, 22 March 2025 18:50:48 Greenwich Mean Time Dale wrote:
> Howdy,
>
> As most know from other threads, I have a couple external m.2 NVME SSD
> drives thingys. As of today, I now have a Crucial 480GB and 1TB and a
> Samsung 1TB drive. I also have a Samsung 1TB m.2 in my main rig for the
> OS. I read some things ages ago about these things when they first came
> out and people were still learning about what to do and not do with
> them. At the time there was a lot of confusion as they were new and
> people were testing options. I figure by now, it is fairly well known
> what not to do with these things and what should be done to make them
> perform well and last longer. So, I have questions but also feel free
> to share other info as well that would be good to know. I plan to make
> a cheat sheet out of the info.
>
> First, for mount options. Should I have any mount options included in
> fstab for the OS m.2 in my main rig?
Yes, noatime
Also, depending on your filesystem choice you could benefit from compression.
For more esoteric formatting on RAID arrays and assuming the necessary
information is provided by the OEM, read here about block erase size:
https://wiki.gentoo.org/wiki/SSD
Finally, consider TRIM being run on a cron job, or better use something like
the SSDcronTRIM script once a month to decide and execute fstrim if needed.
NOTE: With LUKS encrypted partitions you have to pay particular care - TRIM
can compromise the security of your data and LUKS devs warn about it.
However, on a drive with a lot of re-write ops you will at some point need/
want to run fstrim. In this case you'll have to run cryptsetup with '--allow-
discards', before you run fstrim.
> Also, for the external USB mounted
> ones, should I put mount options somewhere for those? If so, since
> there is no fstab entries, where would I put those options? Some I use
> the automount tool built into KDE.
You can create udev rules to apply any options you need, but I don't know what
options may be applied by default by udev. Bear in mind, preferred mount
options depend not only on the filesystem, but also on the USB controller and
its ability to process SCSI commands (e.g. dumb UFDs Vs smart(er) UAS).
> Now to add more questions. I'm sure running shred, dd, wipe and other
> similar commands would shorten the life of one of these things. Is
> there other things I should avoid doing that is common on spinning rust
> drives? Are there any other don'ts I should be aware of?
With older SSDs you may need to leave some spare capacity unused
(overprovisioning). Modern SSDs apply firmware based overprovisioning
transparently to the user, and you are going to be filling them up
relentlessly you should be able to increase the overprovisioning amount by
using the OEM's utility software, or hdparm.
https://www.thomas-krenn.com/en/wiki/SSD_Over-provisioning_using_hdparm
Personally, I just leave some non-partitioned space more as a force of habit
than need.
> Are there things I should do on occasion that will make them perform
> better, last longer or both? Keep in mind, some may only be mounted
> with USB. That may limit some options. So far, the m.2 enclosure I use
> allows SMART to get info at least. Oh, what info does SMART give that I
> should keep a eye on for failures or problems? I also installed a
> package that includes the nvme command. I'm not real sure what to do
> with that thing, yet. o_o
You probably want to alter the cache path for your browser from the SSD drive
to your RAM (tmpfs), especially if you have a lot of RAM. Consider the same
for any configurable applications which are caching heavily.
Also, if you use swap, then use zswap to reduce the amount written to the
disk.
> Now that I have a few of these things, I don't want to do something that
> lets the smoke out. O_O Oh, links to good info would also be OK.
>
> Thanks.
>
> Dale
>
> :-) :-)
You wouldn't go wrong by starting with these two pages:
https://wiki.gentoo.org/wiki/NVMe
https://wiki.gentoo.org/wiki/SSD
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2025-03-22 21:38 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-22 18:50 [gentoo-user] What are common SSDs does and don'ts Dale
2025-03-22 19:29 ` Mark Knecht
2025-03-22 21:37 ` Michael [this message]
2025-03-23 1:48 ` Dale
2025-03-23 9:00 ` Michael
2025-03-23 21:41 ` Dale
2025-03-23 22:15 ` Nate Eldredge
2025-03-23 22:32 ` Frank Steinmetzger
2025-03-23 23:24 ` Dale
2025-03-31 21:27 ` Frank Steinmetzger
2025-04-01 0:44 ` Dale
2025-04-01 10:01 ` Peter Humphrey
2025-04-01 10:12 ` Dale
2025-04-01 10:24 ` Peter Humphrey
2025-04-01 12:56 ` Dale
2025-04-01 13:13 ` Peter Humphrey
2025-04-02 3:33 ` Dale
2025-04-02 11:13 ` Peter Humphrey
2025-04-01 11:04 ` Michael
2025-04-01 13:03 ` Dale
2025-04-01 15:44 ` Michael
2025-04-02 4:04 ` Dale
2025-04-02 8:29 ` Michael
2025-04-07 18:28 ` Dale
2025-04-01 22:46 ` Frank Steinmetzger
2025-04-01 23:08 ` Frank Steinmetzger
2025-04-02 4:03 ` Dale
2025-03-23 4:34 ` Matt Jolly
2025-03-23 6:56 ` netfab
2025-03-23 7:01 ` Dale
2025-03-23 7:03 ` netfab
2025-03-23 22:46 ` Frank Steinmetzger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3275233.5fSG56mABF@rogueboard \
--to=confabulate@kintzios.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox