Questions about Installing Mageia5 on an SSD

[banjo]

I am building a new computer to install Mageia 5 on, and I plan on putting an SSD in it. Here is the basic setup:

SSD is a Crucial BX100 CT500BX100SSD1 2.5" 500G SSD
Intel Core i5-4590 Haswell Quad-Core
8 Gig of RAM
Graphics card etc.

I am confused about what I need to do to make the SSD work in the new computer. I have not used an SSD before.

I have read the blogs and the wiki's and the tips and tricks about using an SSD on Linux, and I came away more confused than ever. There does not seem to be a consistent story, and I suspect that a lot of the information is out of date.

The advice that I see is to add "discard" to /etc/fstab and don't add "discard" to /etc/fstab. Turn on TRIM and don't turn on TRIM. Always use Gparted to preformat the drive before installation, and don't bother because DrakX and do that for you on the 1 Meg boundaries.

I have read about not putting swap on it, and put the swap on it but change swappiness, and put the swap in RAM (what on earth could be the point of that?).

Some say that it should not be partitioned at all. How does Linix get installed without / and /home? I have also heard to put a partition on it that is not used to provide extra space for remapping and longevity. But then I have read that the drive does that already anyway so don't bother.

I have also read that you need to turn off logging and browser caching to make the disk drive last longer, but then I also read that modern SSD drives can be put into a server and written with Gigabytes per day and still last for 10 years. I am not going to hit it that hard. Computers don't last 10 years.

I will be building a home desktop system for doing emails, finances, surfing etc. We will not be writing Gigabytes of data to it 24 hours per day. I currently have a 500 Gig rotating disk in my current (Mageia3) computer, and I have used 81G for everything I have done since 2003, when I built my first Linux computer. Really. Everything still fits in 81 Gig. I have 335G left on /home and 27G left on /. I am not a disk hog.

After reading about this for days I am still very confused. What is the real deal? What do I really need to do in order to install Mageia 5 on my SSD?

Is any of this really necessary? Is it old information? If I simply install Mageia 5 on the disk using the classical 64 bit installer, is that going to work well enough?

I am sure that this question has been asked dozens of times already, but my searches of the interwebs has not cleared it up at all.

I am looking forward to upgrading to Mageia 5.

Thanks to all.

[jiml8]

Treat it like any other hard drive when you partition it. And, yes, you have to partition it. The filesystem needs that even if the action is essentially meaningless to the random-access SSD device.

I have two SSDs in my system, and I do turn down swappiness in order to reduce the desire of the kernel to use the swapfile. It is available if required and is not used unless needed.

I also have encrypted filesystems on the SSDs, and this does influence my SSD architecture to a certain extent.

Here is how I handle my SSDs.

In /etc/systemd/system, I have a service named configSSD.service which contains:

Code: Select all

[Unit]
Description = Configure system for SSD drives

[Service]
ExecStart = /usr/local/bin/configSSD

[Install]
WantedBy = basic.target


And the referenced command in /usr/local/bin:

Code: Select all

#!/bin/bash
#  configure for SSDs
echo deadline > /sys/block/sdc/queue/scheduler
echo deadline > /sys/block/sdd/queue/scheduler
echo 10 > /proc/sys/vm/swappiness


My /etc/fstab entry:

Code: Select all

# Entry for /dev/sdc1 : this is an SSD
LABEL=SYSTEM / ext4 defaults 1 1
# Entry for /dev/mapper/crypt_sdc5 :second partition on SSD
LABEL=SDC5 /mnt/sdc5 ext4 relatime,nofail 0 0
# Entry for /dev/mapper/crypt_sdd5 :second partition on second SSD
LABEL=SDD5 /mnt/sdd5 ext4 relatime,nofail 0 0
/dev/mapper/crypt_sdd1 swap swap noatime 0 0


Note that the system boots from /dev/sdc1, which is the only partition in my entire system that is not encrypted.

In /etc/cron.daily, I have the script fstrim:

Code: Select all

#!/bin/sh
#
# To find which FS support trim, we check that DISC-MAX (discard max bytes)
# is great than zero. Check discard_max_bytes documentation at
# https://www.kernel.org/doc/Documentation/block/queue-sysfs.txt
#
LOG=/var/log/trim.log
echo "*** $(date -R) ***" >> $LOG
for fs in $(lsblk -o MOUNTPOINT,DISC-MAX,FSTYPE | grep -E '^/.* [1-9]+.* ' | awk '{print $1}'); do
        fstrim -v "$fs" >> $LOG
done


This script is closely based on one I found when searching the 'net in order to solve a specific problem I had after first installing the SSDs.

I also have set up logrotate to rotate /var/log/trim.log on a monthly basis.

Because my system is encrypted, I have the following entries in /etc/crypttab:

Code: Select all

crypt_sdc5 UUID=47141196-6ce9-4119-9fca-8b8025556cae none luks,discard
crypt_sdd5 UUID=baa966ed-804b-4644-80e6-b2eb1fe5ccc9 none luks,discard


And this works without issue. Hope it helps.

[jiml8]

I will comment further that I did format these using diskdrake in Mageia 4. It handled the boundaries properly.

[banjo]

Thanks for all the information. I will do some research to see what all of that means and how it works. Things are changing so fast in the computer world that I will have to refresh my Linux knowledge again. After all, it has been 2 years since I did this...

Stuff to learn, GRUB2, systemd, UEFI, SSD....

Banjo

[banjo]

One quick question. It looks like you run the script that does

Code: Select all

echo deadline > /sys/block/sdc/queue/scheduler

every time the computer boots. Is that necessary? Does /sys/block/sdc/queue/scheduler default back to cfq each time it boots?

Same question with /proc/sys/vm/swappiness. Does it default back to 60 when the computer boots?

Thanks,
Banjo

[jiml8]

Those values default in the kernel.

I'm pretty sure you could set swappiness in /etc/sysctl.conf by putting the line "vm.swappiness=10" and it would work, but you have to change the disk scheduler after the kernel starts, or by recompiling the kernel with the desired default disk scheduler.

In my particular installation, I also have mechanical hard drives, and I want the cfq scheduler running on those, so setting the scheduler on a per-device basis makes sense.

[doktor5000]

you have to change the disk scheduler after the kernel starts, or by recompiling the kernel with the desired default disk scheduler.

Or by using the kernel option elevator=<scheduler>
Or by using a udev rule, depending on the type of disk: https://wiki.debian.org/SSDOptimization ... -Scheduler
And FWIW, I don't think the discard option in crypttab is necessary in your setup, as you don't use discard mount option.

@banjo: You can use SSDs nowadays just like normal disks. discard (which enables TRIM - on every write access) should not be used as it's not regarded stable yet by kernel developers.
You can use fstrim (which does the same, but not so much impact on performance) but you don't have to. I've used my old SSDs for over 2 years without using TRIM at all - and they still hum along nicely.
You can put swap on the SSD, no problem about that.
You don't need to think about partitioning, as long as you use a recent partitioner. Either gparted, diskdrake or the windows partitioner all pay attention to alignment, and usually align the partitions at 2MB boundaries.

So basically none of that is really necessary. But if you want to squeeze the last 1-3% performance out of your SSD, you can do a lot more, but practically you'll probably never notice it in real life, if you come from a traditional HDD.

In case you want more details on any of those points, just ask.

[jiml8]

Or by using the kernel option elevator=<scheduler>
Or by using a udev rule, depending on the type of disk: https://wiki.debian.org/SSDOptimization ... -Scheduler

Real Men recompile when they want to change options. :p

And FWIW, I don't think the discard option in crypttab is necessary in your setup, as you don't use discard mount option.

You may be right. That option found its way in when I was setting things up, and I noticed it when I first responded on this thread, but have not investigated further at this point.

You can use fstrim (which does the same, but not so much impact on performance) but you don't have to. I've used my old SSDs for over 2 years without using TRIM at all - and they still hum along nicely.

Not so sure about that. I suspect there is a strong dependence on vendor firmware there. My experience with some SSDs is the exact opposite of yours; without TRIM they get very slow after awhile. I would recommend using fstrim until and unless you have positive evidence (probably provided by the hardware manufacturer) that TRIM is not needed.

[doktor5000]

My experience with some SSDs is the exact opposite of yours; without TRIM they get very slow after awhile. I would recommend using fstrim until and unless you have positive evidence (probably provided by the hardware manufacturer) that TRIM is not needed.

Yep, they might get slower. If they get really slow, and it's not some tiny diference only noticeable by using benchmarks, you should use fstrim, agreed.
In general I can also recommend using fstrim, also explained in our wiki: https://wiki.mageia.org/en/Installation_on_a_SSD_(Solid_State_Drive)#The_fstrim_command
Just saying, you don't strictly have to do it - and if you notice the drive performance strongly degrades, you could easily run it once.

[banjo]

Thanks for all the great information. As long as the partitioning will work OK it sounds like I can try the other stuff after I get the system running. It will take a while for me to get to this since I haven't found the time to build the computer yet. The empty crate is sitting next to me. Maybe this weekend.

Banjo
(_)=='=~