Installing OpenSuse 13.1 on SSD

Will OpenSuSE 13.1 install on an SSD with the correct block, page size, and alignment parameters automatically, or will I need to configure the partitions manually? Searching here shows posts regarding only 13.2 and later releases. I would like to install 13.1 - work - and Tumbleweed - trial - on the SSD. I also plan to leave some of the SSD unpartitioned to simplify trim. Any recommendations for what % of the SSD’s capacity should be left free for this purpose?

13.1? so are you planning to use this as Evergreen
Release notes say: https://www.suse.com/releasenotes/i386/openSUSE/13.1/#sec.123.uefi-part

Thank you for the quick reply, but I do not understand what “Evergreen” signifies. I have been searching and reading whatever I can find about SSD with Linux. The intended computer has both UEFI and legacy, although there will be no Windows installed on it. My “research” has left me with a lot of confusion about “trim” and the various articles I have read recommend either edit /etc/fstab mount lines to add "noatime (or relatime) and discard, while others recommend against this and to use fstrim periodically. Then there is the matter of block size and partition alignment, and, as I mentioned, a recommendation to leave unpartitioned free space.

I want to stay with 13.1 because I have other fully functioning installs with it. I tried Leap but cannot get any printer - both HP - to work with it, whether connected by parallel port, USB, or wireless. Tumbleweed comes with an updated hplip and may fix the printer issue, per a response to another post about the printer problem.

I just found this: https://sites.google.com/site/easylinuxtipsproject/ssd
So far, this is the most lucid discussion I have found, and I presume the suggested configurations mutatis mutandis would work with OpenSuSE. I also use Mint now for my Debian install.

I can’t recall in 13.1 what the situation was, but now for Leap 42.1 you just install, only thing you might want to consider is swappiness

Re: Mint did you ever see this
https://sites.google.com/site/easylinuxtipsproject/ssd

13.1 is older and is now supported by the evergreen project which supplies longer term support for selected openSUSE versions. Current version of openSUSE is called leap 42.1 (yes they decided to go all Hitch-hiker on us) .

As to SSD if using the ext4 file system I recommend at minimum to add some peramters to the /etc/fstab mount lines.


noatime,nodiratime,discard,acl,user_xattr

which I use on SSD based EXT4 partitions

noatime,nodiratime stop the recording of read/open date stamps which reduces writes which should increase over all life

discard is the trim operation. some say it is best done periodically via cron process.

I would not recommend BTRFS on 13.1 it was just being introduced and could be unstable somewhat

On LEAP the default file system is now BTRFS and seems to be fine and SSD is supported and should not need any tweaks.(not sure about noatime option)

On modern SSD you can expect reasonable long life assuming normal usage.

Here is one thinking that the “discard” option is overkill, unless you are running a network or DB server, and that trim via fstrim at boot or weekly by a cron job will do for the average personal computer.
A few % uncommitted might help: Samsung suggest 7%, even less might be enough if you don’t write as much data between two successive fstrims.
Lowering swappiness to the minimum is simple and useful, too.

Last tweak worth trying, check file /sys/block/sda/queue/scheduler (assuming your SSD is “sda”): if it doesn’t read "noop [deadline] cfq ", you may add “elevator=deadline” to the kernel boot line, since IIRC the OS 13.1 default is still “cfq” and it is not automatically tweaked to “deadline” for SSD mounts like we see on Leap 42.1.

Anyway, if yours is a new, recently built SSD, relax and take it easy, they are not that fragile anymore…
As to block/page/alignment, with recent SATA SSDs you don’t know where data is actually stored, since that is managed by the SSD firmware AFAIK. So there is no use and no means to “align” data to physical cells: leave that problem to smartphone storage…

Your link brings up the same page as the link I cited.

I just installed Linux Mint 17.3 32-bit on an old Toshiba notebook that was given to me. I installed a PNY 120 GB SSD. The previous owner had "upgraded’ to Windows 10 and the performance was abysmal. The notebook has 2 GB of RAM, so a light weight desktop like “Mate” leaves enough free memory to minimize or eliminate swap. I’ve noted the recommendation on adjusting swappiness. Performance is now quite satisfactory, even with the puny Atom CPU.

Next project is an old HP `17" laptop with a stronger CPU and greater RAM capacity. This will dual boot Mint 17.3 and Tumbleweed, which hopefully has better printer support with its version of hplip.

And many thanks to everyone who took the time and trouble to reply to my query. I think i have enough now to migrate to SSD’s.