Are there any adjustments that should be made to a 42.3 installation?
I read stuff about only using ext4 fs…never btrfs, not installing a swap partition, etc.
Many of these suggestions may be found here,
https://sites.google.com/site/easylinuxtipsproject/ssd-in-opensuse
What are other people doing to their installations to optimize for SSDs? TIA
Currently no - in fact you should under no circumstance mount it with the ssd flag as it can cause more wear on the drive.
Take a peek here; https://btrfs.wiki.kernel.org/index.php/Gotchas#The_ssd_mount_option
Apparently they’re working on a patch that may be released in kernel 4.14 to improve compatibility with modern SSD drives.
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:
https://forums.opensuse.org/showthread.php/511708-openSUSE-on-SSD-optimal-TRIM-config
https://forums.opensuse.org/showthread.php/514176-Installing-OpenSuse-13-1-on-SSD
https://forums.opensuse.org/showthread.php/513630-SSD-Install
or the following SDB pages which are a bit dated material but explain the basic choices available rather well:
https://en.opensuse.org/SDB:SSD_performance
https://en.opensuse.org/SDB:SSD_discard_(trim)_support
… and don’t be afraid to ask here if you still have doubts 
Hi
The only thing I do is reduce swappiness. I have a preference for OCZ SSDs, no intel or samsung devices…
I don’t use big SSD’s (< 240GB) and keep important things copied off to a NAS.
Do you just have an SSD or do you also have a mechanical HD?
Every time a system is installed on, or upgraded to using an SSD,
The ArchWiki page for SSDs should always be newly consulted for each and every install. It’s maintained and updated constantly to reflect news.
https://wiki.archlinux.org/index.php/Solid_State_Drives
The first thing that should always be checked is always at the bottom of this page… For some disk vendors (particularly Sandisk and Samsung) there may be a firmware update.
After that, common features which should be enabled or changed from default are
If the disk is second hand or grey market, you may want to do a “factory wipe” as described in the Wiki which would be far more complete than ordinary cell clearing.
TSU
I am using fstrim and let cron do the job daily to trim /home and /.
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?
See my previous post emphasizing the need for a firmware upgrade on certain popular Samsung models.
TSU
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.
Hi
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
Docs: man:fstrim
Aug 06 13:25:26 grover systemd[1]: Started Discard unused blocks once a week.
Hi
That’s why I like OCZ SSD’s, they have a standalone linux iso firmware updater/checker etc.
Negative. It was exhibiting this behavior when it was a daily driver running 42.2, as well as after the 42.3 install on blanked partitions.
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.
TSU