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?
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.
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.
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.
OK, I went ahead and converted my root partition from ext2 to ext4.
Some notes, observations and questions:
For starters, I booted up Parted Magic.
Using the Partitioner(Gparted), I made some space on one of my large hard drives to store an image file as a backup)
Using Clonezilla, I made a backup image of /dev/sda2, my SSD root partition.
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.
From the xfce desktop, I opened an Xterm window and became root (with su, no passwords needed)
I followed the procedure in this Reference1 to make the ext2 to ext4 conversion and run checks.
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.
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.
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.
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.