Hi, generally speaking that is a fairly good guide, I use some of those hints in my installs; please note the remark “1. First a word of caution: don’t exaggerate! There’s a lot of exaggeration to be found on the web on this issue.”
That said, SSDs are more robust currently than when the guide was originally written and BTRFS is no more as bad as it was back then, so some SSD users just install Leap with default settings.
Personally I prefer EXT4, reduce swappiness and use fstrim at boot (on laptops), keeping a SWAP for suspend-to-disk (AKA hibernate).
Other members disagree or use other measures, so it’s entirely up to you depending on your user profile.
There are a number of threads on the subject, which periodically resurface at every openSUSE release, see for instance the following:
Excellent advice here. Thanks for the responses. I have (2) Thinkpad T61 laptops, both run Samsung SSDs as the primary hard drive. One of them has been “freezing” randomly in recent months. It will lock up for approximate 10 seconds to one minute a couple or more times a day. I’ve narrowed the problem down to the SSD by swapping components into the other laptop. The problem occurred when I had 42.2 installed on the drive as well as 42.3. Both installs are stock openSuse install using defaults suggested by the installer. An thoughts regarding what is causing the freeze-ups?
A very wild guess… your disk might be almost full.
Apparently Samsung SSDs need some uncommitted space (some 7% is what the Win* Samsung tool does) and/or regular fstrim (or discard) to work smoothly. If not so, when nearly full the disk FW might “pause” for a while blanking unused (but still “not blank” due to prior usage) cells, to be able to write new data.
Never seen something similar on my EVO 840 with regular fstrim.
There should be a trim service running that will do that automatically for you…?
systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Sun 2017-08-06 13:25:26 CDT; 21h ago
Aug 06 13:25:26 grover systemd: Started Discard unused blocks once a week.
The thing about TRIM (ie discard) on Linux is that there really isn’t an intelligent solution (AFAIK) that ensures optimum and efficient operation that guarantees available cells(aka traps).
Especially if run as a CRON job, it’s only a guess which can be very far off… Depending on your personal disk activity and the overall unused disk space, you may or may not be able to run TRIM daily to satisfy your need. And, if your system finds itself with insufficient available cells, then you’ll see the described behavior “on demand.”
That is why it’s advisable when possible to invoke your TRIM (aka discard) command as part of your fstab instead as a CRON job… that way the operation should be executed as a low priority background job, invisible and constant which should do a better job of ensuring you can use your disk when you want to.