Results 1 to 8 of 8

Thread: Install Leap 15.1 on new ssd drive

  1. #1
    Join Date
    Oct 2012
    Location
    Malaysia
    Posts
    4

    Default Install Leap 15.1 on new ssd drive

    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

  2. #2
    Join Date
    Oct 2008
    Location
    Glasgow, Scotland
    Posts
    1,144

    Default Re: Install Leap 15.1 on new ssd drive

    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.
    ~Thank you for sharing an interesting problem.
    --
    slàinte mhath,
    rayH

  3. #3
    Join Date
    Dec 2008
    Location
    FL, USA
    Posts
    1,752

    Default Re: Install Leap 15.1 on new ssd drive

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

    https://doc.opensuse.org/documentati...tup/index.html
    Reg. Linux User #211409 *** multibooting since 1992
    Primary: 42.3,TW,15.0 & 13.1 on Haswell w/ RAID
    Secondary: eComStation (OS/2)&42.3 on 965P/Radeon
    Tertiary: TW,15.0,42.3,Fedora,Debian,more on Kaby Lake,Q45,Q43,G41,G3X,965G,Cedar,Caicos,Oland,GT218&&&

  4. #4
    Join Date
    Jan 2017
    Location
    Nürnberg, Germany
    Posts
    188

    Default Re: Install Leap 15.1 on new ssd drive

    Quote Originally Posted by mrmazda View Post
    Why do you think installing to SSD is different than installing to HD?
    Several reasons:

    • 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.
    • 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:
      Code:
      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.
    • 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
      • no swap partition
      • the »deadline« scheduler instead of other schedulers based on HDD mechanics
      • a custom and non-compressed initrd (initial RAM disk), see my detailed description here.
    • 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.

    As you can see, there are all kinds of differences between SSDs and spinning disks. Cheers!

  5. #5
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    27,071
    Blog Entries
    15

    Default Re: Install Leap 15.1 on new ssd drive

    Quote Originally Posted by unix111 View Post
    Several reasons:

    • 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.
    • 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:
      Code:
      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.
    • 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
      • no swap partition
      • the »deadline« scheduler instead of other schedulers based on HDD mechanics
      • a custom and non-compressed initrd (initial RAM disk), see my detailed description here.

    • 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.

    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..
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  6. #6
    Join Date
    Sep 2012
    Posts
    5,184

    Default Re: Install Leap 15.1 on new ssd drive

    Quote Originally Posted by unix111 View Post
    »trim« ... is necessary for the internal SSD storage management to achieve optimal wear-leveling.
    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.

  7. #7
    Join Date
    Dec 2008
    Location
    FL, USA
    Posts
    1,752

    Default Re: Install Leap 15.1 on new ssd drive

    Quote Originally Posted by unix111 View Post
    As you can see, there are all kinds of differences between SSDs and spinning disks. Cheers!
    And you think the YaST installer knows nothing about taking differences into account? e.g.
    Code:
    # 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.
    Reg. Linux User #211409 *** multibooting since 1992
    Primary: 42.3,TW,15.0 & 13.1 on Haswell w/ RAID
    Secondary: eComStation (OS/2)&42.3 on 965P/Radeon
    Tertiary: TW,15.0,42.3,Fedora,Debian,more on Kaby Lake,Q45,Q43,G41,G3X,965G,Cedar,Caicos,Oland,GT218&&&

  8. #8
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    1,061

    Default Re: Install Leap 15.1 on new ssd drive

    Quote Originally Posted by matfx View Post
    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
    The same procedure as with every version: https://www.linuxtechi.com/opensuse-...e-screenshots/

    Code:
    :~> 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.
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), openSUSE Tumbleweed, KDE Plasma 5

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •