Installing 13.2 on Solid State Drive (SSD): minor tweaks

Here is a list of tweaks that I did during my SSD install on 13.1 last year. I have just repeated this for the new 13.2 release.

1-use ext4 as file type during install and leave 7% of SSD capacity unformatted.

2-Lowering swappiness. Edit /etc/sysctl.conf by
    inserting, "vm.swappiness=1", and "vm.vfs_cache_pressure=50"
    
3-Making tempfs for tmp. Insert this in fstab,
    tmpfs                /tmp                 tmpfs      defaults,noatime  

4-Add noatime to fstab entries for root partition and other Linux partitions (except swap). Table might look something like this... 

    /dev/disk/by-id/ata-WDC_WD2500BEVT-22A23T0_WD-WX61C50H7642-part6 /                 ext4       noatime,acl,user_xattr        1 1
    /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSADC17408K-part5 swap           swap       defaults              0 0
    /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSADC17408K-part6 /              ext4       acl,user_xattr,discard,noatime 1 1
    /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSADC17408K-part7 /home          ext4       acl,user_xattr,discard,noatime 1 2
    tmpfs                /tmp                 tmpfs      defaults,noatime              0 0
    /dev/disk/by-id/ata-HGST_HTS721010A9E630_JG40006EG6NMJC-part1 /external            ext4       defaults,noatime              1 2

5- Automating TRIM on boot by boot.local. Add the "fstrim -v /" to /etc/rc.d/boot.local. 

6- Limit browser write actions by setting cache to zero. 
    Firefox-Menu button (with the three dashes on it) --> Preferences --> Advanced --> Tab Network --> section Cached Web Content: tick Override automatic             cache management and set the cache to 0 MB.
    Chrome- with Chrome open press the F12 key to access the developers' console. Click on the gear wheel in the bottom right for settings. Select disable             cache.

7-Change the I/O scheduler to deadline. Open /etc/default/grub. Change this:
    GRUB_CMDLINE_LINUX_DEFAULT=" resume=/dev/disk/by-id/ata-WDC_WD2500BEVT-22A23T0_WD-WX61C50H7642-part5 splash=silent quiet showopts"
    to this:
    GRUB_CMDLINE_LINUX_DEFAULT=" resume=/dev/disk/by-id/ata-WDC_WD2500BEVT-22A23T0_WD-WX61C50H7642-part5 splash=silent quiet showopts elevator=deadline"
    by adding the option elevator=deadline to the end. Save and close.
    Update Grub by running, "grub2-mkconfig -o /boot/grub2/grub.cfg" as SU.

This is based on general instructions on this webpage: https://sites.google.com/site/easylinuxtipsproject/ssd-in-opensuse
Is there anything else that openSuse users are doing for SSD installs that I’ve overlooked? TIA.

I’ve installed a 250 GB EVO 840 a couple days ago. Some things I think may be interesting:

  1. I’d guess that setting the scheduler in the boot parameter will also affect the HDDs (I have four in this machine, plus the SSD).
echo deadline > /sys/block/sda/queue/scheduler

This works from the terminal, as root obviously, for the specified drive (sda) only. You can cat it to check.

To set it globally you can also use Yast2 > Kernel Settings.

  1. Since /home is also on the SSD, shouldn’t you trim it too? I included it in boot.local just now, still have to reboot to see if it works. boot.local is like this for now:
echo deadline > /sys/block/sda/queue/scheduler
fstrim -v /
fstrim -v /home
  1. According to https://sites.google.com/site/easylinuxtipsproject/ssd-in-opensuse you should be able to redirect the firefox cache folder to the HDD, better than downloading every web page component again every time you visit it.

about:config –> browser.cache.disk.parent_directory

This variable do not exist in my browser, perhaps it need to be created?

I also assigned /tmp and /var/log to 1GB partitions in one of the HDDs, the only precaution is to change my disk burner (K3b) temp folder to somewhere bigger, or I won’t be able to burn 4GB DVDs. Apparently /tmp in RAM is OK, but I do want to keep the logs.

What do you think?

After a reboot:

  1. The *echo deadline *> … command in boot.local works:
~> cat /sys/block/sda/queue/scheduler
noop **deadline**] cfq 
~> cat /sys/block/sdb/queue/scheduler
noop deadline [cfq] 
~> cat /sys/block/sdc/queue/scheduler
noop deadline [cfq] 
~> cat /sys/block/sdd/queue/scheduler
noop deadline [cfq] 
~> cat /sys/block/sde/queue/scheduler
noop deadline [cfq] 
  1. No error messages in dmesg about fstrim, so I suppose it works. I’ll probably change it to -v and dump the output to a file, to check.

There’s a lot of conflicting opinions about scheduling/doing fstrim at boot x using discard in fstab. I’m keeping with boot.local for now based on the man page for fstrim, that state:

Running fstrim frequently, or even using mount -o discard, might negatively affect the lifetime of poor-quality SSD devices. For most desktop and server systems the sufficient trimming frequency is once a week.

Since I reboot this machine about once a week, I figure it’s OK. Not that a 840 EVO is poor-quality, of course, I’m looking at the frequency suggested, and I suppose the guy who developed the tool knows what he is talking about.

  1. Creating the new setting in about:config works. Also, about:cache will show cache info, including current location. Setting a new location will immediately create a new cache directory, …/cache2 in my case, as I didn’t remove the original cache first.

On Wed 17 Dec 2014 06:16:02 AM CST, brunomcl wrote:

After a reboot:

  1. The -echo deadline -> … command in boot.local works:

Code:

~> cat /sys/block/sda/queue/scheduler
noop deadline] cfq
~> cat /sys/block/sdb/queue/scheduler
noop deadline [cfq]
~> cat /sys/block/sdc/queue/scheduler
noop deadline [cfq]
~> cat /sys/block/sdd/queue/scheduler
noop deadline [cfq]
~> cat /sys/block/sde/queue/scheduler
noop deadline [cfq]

  1. No error messages in dmesg about fstrim, so I suppose it works. I’ll
    probably change it to -v and dump the output to a file, to check.

There’s a lot of conflicting opinions about scheduling/doing fstrim at
boot x using discard in fstab. I’m keeping with boot.local for now based
on the man page for fstrim, that state:
> Running fstrim frequently, or even using mount -o discard, might
> negatively affect the lifetime of poor-quality SSD devices. For most
> desktop and server systems the sufficient trimming frequency is once a
> week.
Since I reboot this machine about once a week, I figure it’s OK. Not
that a 840 EVO is poor-quality, of course, I’m looking at the frequency
suggested, and I suppose the guy who developed the tool knows what he is
talking about.

  1. Creating the new setting in about:config works. Also, about:cache
    will show cache info, including current location. Setting a new location
    will immediately create a new cache directory, …/cache2 in my case, as
    I didn’t remove the original cache first.

Hi
No need to trim etc as this is taken care of via a cron job if your
running btrfs? Add elevator=deadline (I use noop) in the kernel boot
options instead.

I have three systems with SSD’s with no noticed degradation in
performance or lifetime events (via smartctl) to date, to be honest
it’s not worth loosing sleep over IMHO…

Winding swap down is the only thing I do with 8GB of ram…


Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.28-4-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

No, I ended up trading snapshots for space (smaller /), and ended up with EXT4

The scheduler thing, probably it’s just a small optimization, but since I have 4 HDDs and only one SSD, it seemed like a good idea. It certainly won’t hurt.

It’s just my first serious SSD installation, I’m more interested in understanding how it works. Actually writes feel a bit faster in the HDDs than in the SSD. Boot times and read speed are fantastic, thou.

I ended up with 24GB RAM in this machine, and left a small 2GB swap in the SSD, just in case later I take some memory out for another machine.

OBS: I also left space on the SSD for bcache, but couldn’t implement it because the partition I wanted to cache already existed, a big one. Also what’s in it wouldn’t actually benefit from being cached, and I was able to put all my working directories in the SSD /home.

After the kernel security update today I had to reboot, so before that I edited boot.local to redirect fstrim output to a file. After reboot this file has:


/: 10.8 GiB (11534991360 bytes) trimmed
/home: 66.9 GiB (71795351552 bytes) trimmed

So I suppose it is working OK.

Only minor comment regarding the above,
Commands can be applied in fstab by partition(as described) or by disk if the command is to be applied to all partitions on the disk.

As described (fstab entry by disk) in my PPT installing on SSD many years ago which still applies… if you’re installing on ext4 which until 13.2 was the only recommended fs that supported trim without running a cron job and a special trim app.
https://sites.google.com/site/4techsecrets/slide-presentations-30min

As Malcolm describes, BTRFS(which is now default for the 13.2 root partition) and XFS (default for the User /home partition) have support for SSD. fstab entries for these new file systems should be configured exactly the same (noatime and discard) as for ext4.

TSU