Install Leap 15.1 on new ssd drive

matfx · November 6, 2019, 8:32am

Hi,

Can anyone give me a guide to install openSUSE leap 15.1 on a ssd drive? Sorry i can’t find any documentation.

Thanks in advance.

matfx

eng-int · November 6, 2019, 9:12am

There is nothing special about installing to a SSD. Just follow the standard instructions for installation from a DVD or USB memory (the latter also works for SD memory cards). The default filesystem (BTRFS) installation will take care of hardware specific matters.

mrmazda · November 6, 2019, 9:17am

Why do you think installing to SSD is different than installing to HD?

https://doc.opensuse.org/documentation/leap/startup/single-html/book.opensuse.startup/index.html

unix111 · November 6, 2019, 1:37pm

Several reasons:

[ul]
[li]An SSD works differently from an »rotating-rust« HDD in that storage is managed internally in large blocks rather than sectors. To ensure maximum throughput, partitions have to be aligned properly on an SSD. I use exactly one 2048-sector-aligned ext4 partition for each SSD. This is something the YaST partitioner won’t provide me with. Even with manual intervention, YaST will warn and complain. At least, alignment is handled automatically during partitioning, from what I’ve read. But it can’t hurt to verify the partitions start at sector numbers divisible by 2048.
[/li]
[li]Another difference: while free space on HDDs doesn’t need to be managed differently than occupied space, SSD admins need to provide for mechanisms called »discard« or »trim« to mark free storage space every few weeks or so. This is necessary for the internal SSD storage management to achieve optimal wear-leveling. It’s also why, after each backup run (once or twice a month, dependent on activity), I enter this command in a root shell: [/li]```
fstrim -v /

 (Your SSD mount points may vary.) This gives the SSD back all non-allocated filesystem storage (deleted files etc.), and it ensures the SSD stays fast and reliable as long as possible during its lifetime. 

[li]Because SSDs are so much more performant than HDDs, it’s worthwile to rethink old (but possibly incorrect) wisdom: For example, caching/scheduling strategies and swap partitions might be superfluous or even detrimental with SSDs. That’s why I use [LIST]
[/li][li]no swap partition
[/li][li]the »deadline« scheduler instead of other schedulers based on HDD mechanics
[/li][li]a custom and non-compressed initrd (initial RAM disk), [see my detailed description here](https://forums.opensuse.org/showthread.php/537299-Extremely-slow-boot-for-new-tumbleweed-gnome-installation?p=2912397#post2912397).
[/li][/ul]
[li]Power-saving features that made sense with HDDs (flush/sync out data before spinning the HDD down) don’t make sense with SSDs. Due to its nature, an SSD performs internal background jobs like wear-levelling even if it’s supposed to have »spun down«, and because of that activity, may use more power than an attached HDD on standby. This may become important in all kinds of scenarios from mobile/personal/embedded use all the way to datacenter deployment. 
[/li][/LIST]
As you can see, there are all kinds of differences between SSDs and spinning disks. Cheers!

malcolmlewis · November 6, 2019, 2:02pm

unix111:

Several reasons:

[ul]
[li]An SSD works differently from an »rotating-rust« HDD in that storage is managed internally in large blocks rather than sectors. To ensure maximum throughput, partitions have to be aligned properly on an SSD. I use exactly one 2048-sector-aligned ext4 partition for each SSD. This is something the YaST partitioner won’t provide me with. Even with manual intervention, YaST will warn and complain. At least, alignment is handled automatically during partitioning, from what I’ve read. But it can’t hurt to verify the partitions start at sector numbers divisible by 2048. [/li][li]Another difference: while free space on HDDs doesn’t need to be managed differently than occupied space, SSD admins need to provide for mechanisms called »discard« or »trim« to mark free storage space every few weeks or so. This is necessary for the internal SSD storage management to achieve optimal wear-leveling. It’s also why, after each backup run (once or twice a month, dependent on activity), I enter this command in a root shell: [/li]```
fstrim -v /
 (Your SSD mount points may vary.) This gives the SSD back all non-allocated filesystem storage (deleted files etc.), and it ensures the SSD stays fast and reliable as long as possible during its lifetime. 
[li]Because SSDs are so much more performant than HDDs, it’s worthwile to rethink old (but possibly incorrect) wisdom: For example, caching/scheduling strategies and swap partitions might be superfluous or even detrimental with SSDs. That’s why I use[/li][LIST]
[li]no swap partition [/li][li]the »deadline« scheduler instead of other schedulers based on HDD mechanics [/li][li]a custom and non-compressed initrd (initial RAM disk), [see my detailed description here](https://forums.opensuse.org/showthread.php/537299-Extremely-slow-boot-for-new-tumbleweed-gnome-installation?p=2912397#post2912397). [/li][/ul]
  
[li]Power-saving features that made sense with HDDs (flush/sync out data before spinning the HDD down) don’t make sense with SSDs. Due to its nature, an SSD performs internal background jobs like wear-levelling even if it’s supposed to have »spun down«, and because of that activity, may use more power than an attached HDD on standby. This may become important in all kinds of scenarios from mobile/personal/embedded use all the way to datacenter deployment. [/li][/LIST]
As you can see, there are all kinds of differences between SSDs and spinning disks. Cheers!

Hi
I do nothing with my SSD’s accept the defaults and haven’t looked back, by default mq-deadline is selected on Tumbleweed, consider switching to that on Leap 15.1. The only thing I steer away from is Samsung devices, maybe they are more popular so show some prominence in having issues(?), plus some still blacklisted by the kernel…

arvidjaar · November 6, 2019, 3:47pm

TRIM has very little to do with wear leveling. TRIM helps to reduce overhead of garbage collection and increase flash lifetime because SSD has less data to copy around (it does not need to copy deleted data) and so less data to write wasting endurance.

OTOH with dumb SSD controller TRIM may actually defeat natural wear leveling due to fragmentation by allowing controller to reuse empty erase block prematurely.

mrmazda · November 6, 2019, 4:02pm

And you think the YaST installer knows nothing about taking differences into account? e.g.

# systemctl status fstrim.service
● fstrim.service - Discard unused blocks on filesystems from /etc/fstab
   Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled)
   Active: inactive (dead) since Mon 2019-11-04 00:00:08 EST; 2 days ago
     Docs: man:fstrim(8)
  Process: 2951 ExecStart=/usr/sbin/fstrim -Av (code=exited, status=0/SUCCESS)
 Main PID: 2951 (code=exited, status=0/SUCCESS)
# 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 2019-11-03 23:12:10 EST; 2 days ago
  Trigger: Mon 2019-11-11 00:00:00 EST; 4 days left
     Docs: man:fstrim

AFAIK, you’ve got alignment backwards. RR’s got 4k sectors and 512b emulation >8 years ago, and the partitioners have been incorporating alignment by default since around that time. OTOH, all my SSDs are showing optimal and physical I/O size identically at 512b. Thus sector alignment is needed for RR, while a non-issue for SSD, not helping or hurting anything.

karlmistelberger · November 6, 2019, 5:13pm

The same procedure as with every version: https://www.linuxtechi.com/opensuse-leap-15-installation-guide-screenshots/

:~> inxi -D
Drives:    Local Storage: total: 2.50 TiB used: 273.61 GiB (10.7%) 
           ID-1: /dev/sda vendor: Samsung model: SSD 850 EVO 500GB size: 465.76 GiB 
           ID-2: /dev/sdb vendor: Seagate model: ST2000DM001-1CH164 size: 1.82 TiB 
           ID-3: /dev/sdc vendor: Samsung model: SSD 850 EVO 250GB size: 232.89 GiB 
:~>

My installs are all on SSD and I never care about details.