Hello,
I would like to ask you about configuration of SSD best/recommended practices in openSUSE Leap/Tumbleweed.
You are certainly more experienced then me 
I want to use Goodram CX400 SSD drive.
My installation:
*45G / (encrypted btrfs with subvolumes)
*the rest /home (encrypted btrfs with subvolumes)
What should I configure?
I’ve heard about trim, separated /tmp, zram/zswap, I/O Scheduler, disabling SWAP on SSD.
Life and efficiency of SSD is very important for me.
Thank you in advance
PS. The best advises I would like to put on openSUSE Wiki for other users
ahhhrrreeecccek2710,
this reminds me of my purchase of an electric guitar, where the salesman told me never to plug the 1/4" mono cable between the amplifier and the guitar differently.
So the side that was previously in the guitar should never ever be connected to the amplifier! rotfl!
A SSD is not a glass cannon. Most times a SSD will even survive your hard drive. They are much more temperature resistant shock resistant and are far less complex in structure. Most voodoo articles about SSDs don’t mention that also hard drives can only handle a limited number of writes (and reads). This is not due to the material or technique, but to other mechanical reasons.
In difference to SSDs their cycles can’t be calculated and that is the reason why we are talking about operation times with hard drives rather than cycles and amount of writes.
And that feels simply different - but it is not!
As long as we are talking about a regular client computer, SSD usage should be a no-brainer. I remember an article several years ago in a german computer magazine where the vendor gives a guarantee of 150TB before the SSD will be broken. That means you have to write ~70GB of data every day for 6 years (no weekend, no vacation, etc. …) to reach that limit. That is completely unrealistic in normal usage. Most times, you are just reading form your SSD. But even more…
The 150TB limit were exceeded in that test by a factor of 30 to ~4000TB in reality.
That is not a guarantee, but it may reduce your worries. You will simply replace your SSD in terms of more speed and capacity before you will reach that limit of cycles. And a backup is needed anyway for so many reasons.
The most interesting option is: TRIM
https://en.opensuse.org/SDB:SSD_performance#TRIM
What makes sense and what is nonsense depends in my opinion strongly by your special needs or usage.
For example, if you often compile software form source it could be a wise choice to do that in a tmpfs - also because the I/O on RAM is much higher.
But, KISS -> Keep it simple, stupid
The system should be comfortable for you and your needs. Not for the SSD.
btrfs recognizes the underlying device is SSD and does some optimizations. Also by default fstrim.service is enabled and an appropriate I/O scheduler is picked.
/tmp is by default a tmpfs mount. See: openSUSE:Tmp on tmpfs - openSUSE Wiki
ZRAM is a good way to avoid swapping to your SSD drive. If you don’t need hibernation then you don’t even need a swap partition. Install systemd-zram-service and enable the zramswap service. It takes care of everything.
:good:
Hi
Aside from the systemd one (It’s a number of years old now but still works), there is also systemd-swap which allows different compression options via the conf file, I have it built here…
Forget all pesky details an go with defaults, e.g. have one small EFI System Partition:
**3400G:~ #** df -h /boot/efi/
Filesystem Size Used Avail Use% Mounted on
/dev/sdc1 100M 32M 69M 32% /boot/efi
**3400G:~ #**
The rest is allocated to a single BTRFS partition with standard subvolumes:
**3400G:~ #** btrfs subvolume list /mnt
ID 256 gen 1480 top level 5 path @
ID 257 gen 837 top level 256 path @/var
ID 258 gen 839 top level 256 path @/usr/local
ID 259 gen 841 top level 256 path @/tmp
ID 260 gen 843 top level 256 path @/srv
ID 261 gen 845 top level 256 path @/root
ID 262 gen 847 top level 256 path @/opt
ID 263 gen 849 top level 256 path @/home
ID 264 gen 851 top level 256 path @/boot/grub2/x86_64-efi
ID 265 gen 853 top level 256 path @/boot/grub2/i386-pc
ID 266 gen 1480 top level 256 path @/.snapshots
ID 267 gen 1480 top level 266 path @/.snapshots/1/snapshot
ID 275 gen 84 top level 266 path @/.snapshots/2/snapshot
**3400G:~ #**
Use defaults for mounting:
**3400G:~ #** cat /mnt/@/.snapshots/2/snapshot/etc/fstab
UUID=36e8edd4-d99e-4e13-a998-8c101d9cba75 / btrfs defaults 0 0
UUID=36e8edd4-d99e-4e13-a998-8c101d9cba75 /.snapshots btrfs subvol=/@/.snapshots 0 0
UUID=36e8edd4-d99e-4e13-a998-8c101d9cba75 /var btrfs subvol=/@/var 0 0
UUID=36e8edd4-d99e-4e13-a998-8c101d9cba75 /usr/local btrfs subvol=/@/usr/local 0 0
UUID=36e8edd4-d99e-4e13-a998-8c101d9cba75 /tmp btrfs subvol=/@/tmp 0 0
UUID=36e8edd4-d99e-4e13-a998-8c101d9cba75 /srv btrfs subvol=/@/srv 0 0
UUID=36e8edd4-d99e-4e13-a998-8c101d9cba75 /root btrfs subvol=/@/root 0 0
UUID=36e8edd4-d99e-4e13-a998-8c101d9cba75 /opt btrfs subvol=/@/opt 0 0
UUID=36e8edd4-d99e-4e13-a998-8c101d9cba75 /home btrfs subvol=/@/home 0 0
UUID=36e8edd4-d99e-4e13-a998-8c101d9cba75 /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0
UUID=36e8edd4-d99e-4e13-a998-8c101d9cba75 /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0
UUID=404C-1EC8 /boot/efi vfat defaults 0 2
**3400G:~ #**
Leap allocates /tmp to disk. Tumbleweed allocates it to RAM. No action needed:
**3400G:~ #** mount | grep /tmp
tmpfs on **/tmp** type tmpfs (rw,nosuid,nodev,nr_inodes=409600,inode64)
**3400G:~ #** df -h /tmp
Filesystem Size Used Avail Use% Mounted on
tmpfs 15G 636K 15G 1% /tmp
**3400G:~ #**
Instead of using swap I bought double sized RAM:
[FONT=monospace]**3400G:~ #** inxi -m
**Memory: RAM:****total:** 29.27 GiB **used:** 4.52 GiB (15.4%)
**Array-1:****capacity:** 128 GiB **slots:** 4 **EC:** None
**Device-1:** DIMM_A1 **size:** No Module Installed
**Device-2:** DIMM_A2 **size:** 16 GiB **speed:** 2133 MT/s
**Device-3:** DIMM_B1 **size:** No Module Installed
**Device-4:** DIMM_B2 **size:** 16 GiB **speed:** 2133 MT/s
**3400G:~ #**[/FONT]
That’s all I need.