Migrate to larger SSD - any better thoughts?

I need more SSD space on my 13.1/KDE desktop.

The system has 2 disks, a 64GB SSD for swap and / and a spinning drive for /home.
I need more SSD space.

Afterr a lot of searching, I have concluded that posts #9 and #10 in this forum item provide a reasonable path forward
https://forums.opensuse.org/showthread.php/491462-Moving-openSUSE-to-another-disk?p=2593487#post2593487

Although my system has a UEFI bios, I have been and plan to continue running in legacy mode, booting from the root partition.

fdisk -l

Disk /dev/sda: 64.0 GB, 64023257088 bytes, 125045424 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000ab522

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048      145407       71680    0  Empty
/dev/sda2          145408    16916479     8385536   82  Linux swap / Solaris
/dev/sda3   *    16916480   125018111    54050816   83  Linux

Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes, 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000678af

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048  2920585215  1460291584   83  Linux


Any better/additional ideas (Aside from doing a backup;done) before I continue?

Thanks in advance.

Hi !

64GB usually should be more than enough for ‘/’ but you don’t tell why you need more, and at the end of the day that’s your business.

Besides, it would be helpful if you installed a second openSUSE on your ‘spinning drive’ (or hard disk),
because you then just could boot from there just in case anything would go wrong - speed is only a secondary criterium in such cases …

Similarly here - my PC would be able to UEFI boot, but I still boot in legacy mode as well.

The links that you have given - probably that will work.

I myself used dd to clone a disk. That is simple.

After cloning with dd you will physically have to unplug the old SSD, before reboot.

After reboot from the new SSD with the cloned system on it (try it !),
you may then probably use a partitioner (like GParted) to enlarge the size of the ‘/’ partition on the new SSD.

If all works out fine, you can erase/format your older 64GB SSD.
What do you want to use that one for now?

Good luck
Mike

Thanks for input,Mike.

Some (perhaps) useful thoughts and comments.

  • The Clonezilla I use (PartedMagic) automatically resizes the larger target partition after cloning from the original(smaller). Makes it easy, I pre-partitioned the new SSD.
  • Why a bigger SSD? For sure, 64GB is way more than plenty for Linux root. I create a directory /VboxMachines/… and put all my VM HDD images in there. Makes a big difference when running WindowsVMs (makes it almost tolerable). I also use oversized SSDs to give the internal wear-leveling algorithms plenty of space to work in.
  • I have become quite fond of this architecture. My 64GB SSD will now move to a new low power home server machine in the swap and root role, for home automation, media server, MyCloud and backups (17Watt dual Celeron, SSD, 2TB Green drive)
  • I am 95% the way there. Clone is complete, ran the edits and new grub2mkconfig. For some reason my Hardware won’t directly boot the new SSD yet, but can be found and started from the Bios Boot Menu. I believe I need to do some additional config in the bios.

Optimize your OS configuration for running SSD.

On Linux, nothing is automatic. If you don’t enable optimizations, your SSD can become dead slow after extensive disk activity (particularly writes).
Although I created my PPT slide deck for 12.2, all the optimizations and recommendations (except for the nVidia issues) are completely relevant to all later versions of openSUSE and <must> be configured.

You should…

  • enable TRIM
  • turn off file system journaling
  • change the I/O scheduler for non-rotational disks (the SSD only, of course)
  • Consider whether modifying “swappiness” is desirable or not
  • Install monitoring apps to know whether your modifications are effective

Other optimizations can be implemented with marginal benefit. The optimizations I describe in my PPT slide deck will have a major effect.

TSU

Thanks … I bet you intended to provide a pointer to you PP deck :wink:

Surely I intended… :slight_smile:

TSU

Thanks, some very interesting and useful information.

I was interested to find that ext4 is now the file system of choice for SSD.
When I first did my install, ext2 seemed to be the recommendation.
I assume the desirability of TRIM is the root reason.

I see numerous references (such as http://www.ghacks.net/2010/08/11/convert-ext23-to-ext4/) about converting ext2 to ext4, but also saw a comment that a converted ext4 does not have ALL the features of a partition formatted from scratch.
Do you happen to know if TRIM is supported on an ext4 partition that has been converted from ext2?

Wouldn’t know.
But I do know that ext4 is the only ext fs with integrated support for TRIM.

Your next best solution is to run a TRIM app manually as a cron job. TRIM wouldn’t automatically run “as needed” as a background job but as a set job so you should schedule it to run either during scheduled very low activity or more often so the job should be shorter.

Or, backup and restore to a new system.

TSU

OK, I went ahead and converted my root partition from ext2 to ext4.
Some notes, observations and questions:

  1. For starters, I booted up Parted Magic.
  2. Using the Partitioner(Gparted), I made some space on one of my large hard drives to store an image file as a backup)
  3. Using Clonezilla, I made a backup image of /dev/sda2, my SSD root partition.
  4. I exited Parted Magic and booted an openSuse 13.1 RescueCD.
    Note - My bios has a nasty habit of booting this CD in UEFI mode, rather than legacy mode; boot in legacy if you want legacy grub2.
  5. From the xfce desktop, I opened an Xterm window and became root (with su, no passwords needed)
  6. I followed the procedure in this Reference1 to make the ext2 to ext4 conversion and run checks.
  7. I then followed the process in Reference2, starting at step 5 to enter the chroot environment on /dev/sda2, made the necessary startup changes to /etc/fstab. I then executed mkinitrd
    to rebuild the initial (boot up) ramdisk, then ran grub2-install (step 14). 1. Exited from chroot, unmounted everything and rebooted.
  8. These steps 1-8 include a lot of triage after my first few attempts, I had to dig for a while to find that the mkinitrd was necessary.

Tsu2, do you have any thoughts on adding /var/tmp to the list of system directories moved to a tmpfs ramdisk? It would appear that this would take care of Web Browser cache disk abuse. This was a suggestion I found back in 2011 when I first converted to SSD.

Thanks for sharing your experience on this topic

By the way, here is info on the SSD

hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
        Model Number:       SanDisk SDSSDXP120G                     
        Serial Number:      141084400034        
        Firmware Revision:  R1311   
        Media Serial Num:   
        Media Manufacturer: 
        Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
        Used: unknown (minor revision code 0x0028) 
        Supported: 8 7 6 5 
        Likely used: 8
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:   16514064
        LBA    user addressable sectors:  234441648
        LBA48  user addressable sectors:  234441648
        Logical  Sector size:                   512 bytes
        Physical Sector size:                   512 bytes
        Logical Sector-0 offset:                  0 bytes
        device size with M = 1024*1024:      114473 MBytes
        device size with M = 1000*1000:      120034 MBytes (120 GB)
        cache/buffer size  = unknown
        Nominal Media Rotation Rate: Solid State Device
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 1   Current = 1
        Advanced power management level: 128
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4 
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
           *    Host Protected Area feature set
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    DOWNLOAD_MICROCODE
           *    Advanced Power Management feature set
                SET_MAX security extension
           *    48-bit Address feature set
           *    Device Configuration Overlay feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    General Purpose Logging feature set
           *    64-bit World wide name
           *    WRITE_UNCORRECTABLE_EXT command
           *    {READ,WRITE}_DMA_EXT_GPL commands
           *    Segmented DOWNLOAD_MICROCODE
           *    Gen1 signaling speed (1.5Gb/s)
           *    Gen2 signaling speed (3.0Gb/s)
           *    Gen3 signaling speed (6.0Gb/s)
           *    Native Command Queueing (NCQ)
           *    Host-initiated interface power management
           *    Phy event counters
           *    unknown 76[15]
           *    DMA Setup Auto-Activate optimization
                Device-initiated interface power management
           *    Software settings preservation
           *    Data Set Management TRIM supported (limit 16 blocks)
           *    Deterministic read ZEROs after TRIM
Security: 
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
                frozen
        not     expired: security count
                supported: enhanced erase
        2min for SECURITY ERASE UNIT. 100min for ENHANCED SECURITY ERASE UNIT. 
Logical Unit WWN Device Identifier: 5001b44be4de15a2
        NAA             : 5
        IEEE OUI        : 001b44
        Unique ID       : be4de15a2
Checksum: correct


I haven’t tracked the very latest location which tmp directory is used for file transfers, but that is the biggest gotcha I’ve encountered mounting as tmpfs.
When a file is moved, a temporary copy is created in a temp directory before that copy is then moved to the target destination, this is so that if the operation fails, it can be rolled back without corrupting the original source file.

Since a tmpfs directories are mounted in RAM, the aggregated max size is then less than your physically installed RAM, so very large file transfers can fail.

So, the openSUSE mount point defaults are probably most reasonable, although you could certainly chase better performance mounting all temp directories as tmpfs.

Congrats on your successful conversion.

IMO,
TSU

OK, thanks for the file transfer thought.

I may give it a try on this machine, I have 16GB of RAM and the tmpfs mounts max out at 7.7G.
Typical ‘idling’ size of /var/tmp is around 300MB.

Seems worth a try; I mostly sleep (STR) this machine, dumping the Firefox cache every so often (with a shutdown) would probably be a good thing.

TSU2 - Another question

On Slide 19 you talk about disabling Journaling on the SSD ext4 partition.
Do the mount options noatime and discard achieve that?

The ARCH reference you provide in the PPT deck (a good read, by the way) seems to say disabling journaling on a ‘modern’ SSD might not be necessary.

By the way, I converted my laptop SSD root partition to ext4 as well, all running !

I also found reference to, and tried, a SuperGrub2 boot disk.
Seems a more accurate way to get grub reinstalled - boot the partition directly with SuperGrub2, then run YAST-bootloader from the running openSuse
The cli methodology descriptions are often fuzzy as to the right steps if/ifnot EFI, for example.

noatime = journaling
discard = TRIM

Disabling journaling should be done only on the partition where the OS resides, you want to enable journaling on any partitions which are used for data primarily, and applications secondarily (if not installed on the root partition). Journaling is supposed to enhance auto error correction and recovery, but is mainly effective when there are reads and writes. Since the OS largely is “write once, read zillions of times thereafter” it’s not that useful in that case.

So, although times may have changed where disabling journaling might not be as effective, it’s still unnecessary so is worth disabling.

TSU