trying to set up SSD Optimizations

[Waldo Jeffers]

In an attempt to set up SSD Optimizations (not blacklisted) i followed this instruction
https://wiki.debian.org/SSDOptimization ... ia_RAMDISK
did

Code: Select all

sudo systemctl enable fstrim.timer
sudo systemctl start fstrim.timer

How to check what's different/ happened?
How to proceed?
Can you use these settings given in https://easylinuxtipsproject.blogspot.c ... d.html#ID3 for Debian too?

[bw123]

Enabling fstrim should be fine. You can try some other tweaks but don't obsess about it. Install smartmontools and check it occasionally.

I've been using 'discard' in fstab for four years on my first ssd with no problems.

[ticojohn]

As I personally have issues with doing anything automatically, as I like to know what's happening, I just make a habit out of running fstrim once a week (usually on Saturday after I have done a backup). I also run fstrim whenever there are significant number of upgrades. But that's just me.

[sunrat]

I'm pretty sure fstrim.timer is set up usually during installation if an SSD is detected. You can check if it is running with:

Code: Select all

systemctl list-timers --all

A lot of SSD optimisation articles on the internet are sadly out of date. Newer SSDs are far advanced from years ago and should give very long service without needing any tweaks. The only things I do now is set AHCI for SATA mode in UEFI/BIOS, and noatime for mounted partitions.

[djk44883]

In an attempt to set up SSD Optimizations (not blacklisted) i followed this instruction
https://wiki.debian.org/SSDOptimization ... ia_RAMDISK

Although that article has recently received some needed update tweaks: https://wiki.debian.org/SSDOptimization?action=info Much of the info is years old.

Initially notes:

/!\ Note that some of the configuration improvements listed below happen automatically today for new installations.

and referenced in another reply...

SSD have matured and become extremely stable and generally should need little to no babysitting.

[Waldo Jeffers]

This is how fstab looks

Code: Select all

# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=5321-A832                            /boot/efi      vfat    defaults,noatime 0 2
UUID=25cc87ef-04cc-4444-9851-7dc0f7a630db /              ext4    defaults,noatime,discard 0 1
UUID=dc3f4a0f-be19-4b83-83bb-6e37e503f844 swap           swap    defaults,noatime,discard 0 0
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

I take it this info is up to date 'Howto: Install and configure Debian Bullseye' At: 4.8 SSD optimization Add noatime
viewtopic.php?f=16&p=746956
Not sure how to act. Add the info to fstab? Delete the existing info first?

[djk44883]

I have a similar entry in fstab for /tmp While re-reading SSDOptimization I came across the notice "/!\ You might also want to be aware of Summary: Moving /tmp to tmpfs makes it useless " Even though it's older than the original article -- SSDs aren't what they used to be... don't need to be "scared" of writing/erasing to them, that's what they're engineered to be used for.

I take it this info is up to date 'Howto: Install and configure Debian Bullseye'

I'm not going to refute anything. They do note "1. Who is this for? This howto is aimed at beginners," So it's great. Until users gain understanding what things mean and impact they have, everyone needs a start. In the end, it's implied they may have used the Debian Wiki as reference: "Further SSD optimization is found here: https://wiki.debian.org/SSDOptimization"

One of the great things with free and open software, particularly Linux system, you can make it look and feel almost how ever you want -- there is not one "best", best is what suits your needs, or one-size-fits all. Although there are best practices.

[postcd]

It is said here http://blog.neutrino.es/2013/howto-prop ... d-dmcrypt/ (8 years old article) that one may need to enable trim on several levels in case of LUKS encrypted SSD drive (my case):

enable on dm-crypt:

Code: Select all

sudo nano /etc/crypttab

options column should contain "discard", like for example: luks,discard

(i already had it there, maybe i added it manually earlier)

enable on LVM:

Code: Select all

sudo sed -i "s|issue_discards = 0|issue_discards = 1|g" /etc/lvm/lvm.conf

(i had it disabled and i enabled it by that command, unsure if right )

enable on filesystem:

Code: Select all

systemctl list-timers --all

possibly it lists fstrim service. If not try to install it. In my case it seems like it should run weekly.
I have tried "sudo fstrim -v /" and it said: /: 23.6 GiB (25352142848 bytes) trimmed
After i run it again in 15 minutes, another 4GB trimmed...
After another minute trimmed 2GB.

Memory shows 13% free, swap is fully utilized. Writing activity seems much lower than to produce/delete 2GB in a minute. Do you have feedback for the things i have mentioned please?

[LE_746F6D617A7A69]

New SSDs don't need TRIM command because the I/O operations are buffered by FW-implemented (usually dynamic) caches.
Such devices can simply ignore the TRIM command - and this is reasonable for devices with R/W MLC caches.

Unfortunately, without testing, it's impossible to know whether the TRIM is needed/supported, because the manufacturers are simply refusing to provide any kind of documentation - all they can do is to sell promises without providing a technical background.

This is (IMO) a violation of a customers rights in most of civilized countries, but nobody cares - SSDs are "so fast" that most of morons wont realize that there's a problem.

Have a nice day.

[p.H]

one may need to enable trim on several levels in case of LUKS encrypted SSD

The cryptsetup man page warns against TRIM on encrypted devices :

WARNING: This command can have a negative security impact because it can make filesystem-level operations visible on the physical device. For example, information leaking filesystem type, used space, etc. may be extractable from the physical device if the discarded blocks can be located later. If in doubt, do not use it.

New SSDs don't need TRIM command because the I/O operations are buffered by FW-implemented (usually dynamic) caches.
Such devices can simply ignore the TRIM command - and this is reasonable for devices with R/W MLC caches.

Can you please explain why such caches make TRIM unneeded ?

[LE_746F6D617A7A69]

Can you please explain why such caches make TRIM unneeded ?

Well, some SSDs are not changing they behaviour even after TRIMming the whole device memory - it's not that TRIM is "unneeded" - It's rather that the caches can compensate for suboptimal writes to all memory areas, independently whether they are marked as unused or not.

But, this works as long as the write cache is sufficient to hold all the write transaction data - when it's not, then results are disastrous - the device is "choking", killing the performance of the whole OS.

[CwF]

- it's not that TRIM is "unneeded" -

Actually as I've pointed out elsewhere, I think it is "unneeded". On device, while active, I never used it. With significant file system slack on any device with high turn over it never comes. Worm style, it never comes up. Now SMR I'd think gets irritated with trim!

[LE_746F6D617A7A69]

- it's not that TRIM is "unneeded" -

Now SMR I'd think gets irritated with trim!

I'm not sure what do You mean by SMR - Shingled Magnetic Recording?

Actually as I've pointed out elsewhere, I think it is "unneeded". On device, while active, I never used it.

Of course, I know that Your SSDs are "very special", and I don't want to start "that discussion" again.

Short history of SSDs:
Technically, TRIM was not needed in the 1st generation of SSDs, that is, for SLC NAND flash chips.
Those devices were so reliable, that there was (almost) no need to implement any error correction algorithms in the NAND Flash controller.
All the newer generations of SSDs are designed to be cheap - the reliable SLC technology has been abandoned in favour of much cheaper but also much less reliable technologies: SLC->MLC->TLC->QLC->PLC.
From technical point of view, MLC and its successors are a complete sh.it: it's impossible to successfully read the memory content without using sophisticated error correction algorithms.
The newer the type of SSDs, the more read errors, and so the stronger error correction algorithms have to be used.
This obviously comes at a cost:
The error correction takes significant amount of time - it slows down the SSD operations long before the memory page becomes completely worn-out (where "completely worn-out" means that the error correction algorithm is no longer able to correct the read errors)

The are 2 main purposes of TRIM command:
1. Writes to an unused (trimmed) SSD memory allows to avoid write-amplification (read-modify-write operations)
2. Because of the above (no read operation), the error correction algorithms are not used, so such write operations can be really fast.

[CwF]

I know that Your SSDs are "very special"

Nope, you said they must be special.
Your conflation. I say they're regular, with a nice usage pattern...
I would think the more a ssd is used to full capacity the more the need for trim, just a hunch.
For the encrypted ones, also never used trim. So in the cycle, only a virt-sparsify every device change, that reveals the extent of space subject to trim during that last cycle, often multiples of the actual data size.