Fine Tuning a new SSD for Slackware.

rkelsen · 08-23-2016, 10:51 PM

Excellent topic. Thanks for posting it.

Many of my long-standing questions were answered.

This is good to know: https://slackalaxy.wordpress.com/2016/01/14/xfs/

cwizardone · 08-23-2016, 11:44 PM

Quote:

Originally Posted by rkelsen

Excellent topic. Thanks for posting it.

Many of my long-standing questions were answered.

This is good to know: https://slackalaxy.wordpress.com/2016/01/14/xfs/

You are very welcome.

kjhambrick · 08-24-2016, 04:59 AM

Quote:

Originally Posted by rkelsen

Excellent topic. Thanks for posting it.

Many of my long-standing questions were answered.

This is good to know: https://slackalaxy.wordpress.com/2016/01/14/xfs/

rkelson --

Yes, this has been educational for me too.

One thing about the link you pasted: it shows how to defragment an xfs filesystem.

While there is a lot of conflicting info on 'SSD Best Practices' out on the 'net, one thing that the HOWTOs are pretty consistent with is 'DO NOT DEFRAG AN SSD'.

I run ext4 so I don't know ... Maybe xfs is 'different' ?

I have my doubts though.

Wear issues aside, an SSD is by design a random access device so fragmentation is not an issue like it is on a spinning HDD platter as long as your SSD is not 'over full'.

-- kjh

kjhambrick · 08-24-2016, 06:17 AM

Quote:

Originally Posted by cwizardone

Certainly not of great import

, but here is the entire post,

Quote:

To: Jörg-Volker Peetz <jvpeetz@xxxxxx>
Subject: Re: ext4 lazytime: ctime of some files changed
From: "Theodore Ts'o" <tytso@xxxxxxx>

<<snip>>

https://www.spinics.net/lists/linux-.../msg86233.html

cwizardone --

I am a terrible writer -- I've got a bad habit of 'jumping to the punchline', leaving my reader confused as to what it is I am trying to say.

Anyhow, I read ALL the messages related to the one you linked and I saw that the Debian user was reporting that the lazytime mount option didn't seem to work on his system.

Ted said, lazytime was 'orthoginal' to relatime -- it does not replace other *time mount options, lazytime instead modifies how and when the *time options work ( man mount ).

Then Ted went thru an exercise on his system to demonstrate how lazytime should work and the lazytime mount option worked for him -- he gets BOTH lazytime AND relatime.

OTOH, in the next message, Jörg-Volker Peetz ( aka jvp, the OP ) did the same exercise on his system and the lazytime option did not work -- all he gets is relatime

The following lines were snipped from Ted's message and then from jvp's followup message:

Code:

# ----- ted's exercise ( note lazytime options for the remounted partition ) ---------------------------
#
# grep sda3 /proc/mounts
/dev/sda3 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0            # note:  no initial lazytime

# mount -o remount,lazytime /
# grep sda3 /proc/mounts
/dev/sda3 / ext4 rw,lazytime,relatime,errors=remount-ro,data=ordered 0 0   # note:  Ted has lazytime
#
# ----- jvp's exercise ( note NO lazytime options for the remounted partition ) ------------------------
#
# grep sda2 /proc/mounts
/dev/sda2 /home ext4 rw,noatime,nobarrier,errors=remount-ro 0 0            # note:  no initial lazytime

# mount -o remount,lazytime /home
# grep sda2 /proc/mounts
/dev/sda2 /home ext4 rw,noatime,nobarrier,errors=remount-ro 0 0            # note:  jvp STILL has NO lazytime

# mount --version
mount from util-linux 2.26.2 (libmount 2.26.0: selinux, assert, debug)     # note:  this is important later on in the thread

Anyhow after reading all the messages in the thread, another Debian User, Holger Hoffstätte ( aka Holger ) figured out how to get lazytime -- revert to util-linux-2.25.2 and he posted a link to another gmane.org thread where I suppose he found the solution to the lazytime mount issue ).

Holger's email is here which is the one I linked.

This made me wonder ...

Slackware 14.2 includes util-linux-2.27.1.

Is the lazytime mount option still broken in util-linux-2.27.1 ? ( punchline == lazytime DOES work )

Code:

# ----- kjh's exercise ( note lazytime works but maybe nolazytime does not ??? ) ------------------------
#
# mount --version
mount from util-linux 2.27.1 (libmount 2.27.0: assert, debug)

# grep sda2 /proc/mounts
/dev/sda2 /boot ext4 rw,noatime,nodiratime,data=ordered 0 0

# mount -o'remount,lazytime' /boot
# grep sda2 /proc/mounts
/dev/sda2 /boot ext4 rw,lazytime,noatime,nodiratime,data=ordered 0 0    # note:  kjh has lazytime

# undo the remount ...

# mount -o'remount,nolazytime' /boot                                    # note:  turn off lazytime
# grep sda2 /proc/mounts
/dev/sda2 /boot ext4 rw,lazytime,noatime,nodiratime,data=ordered 0 0    # HEY !  kjh STILL has lazytime

The lazytime mount option works in Slackware64 14.2.

However, maybe nolazytime does not ??? ( I dunno how nolazytime is supposed to work on a partition already mounted with lazytime ) ???

-- kjh

# man mount

Code:

<<snip>>
lazytime
    Only update times (atime, mtime, ctime) on the in-memory version
    of the file inode.

    This mount option significantly reduces writes to the inode  ta-
    ble  for workloads that perform frequent random writes to preal-
    located files.

    The on-disk timestamps are updated only when:

    - the inode needs to be updated for  some  change  unrelated  to 
    file timestamps

    - the application employs fsync(2), syncfs(2), or sync(2)

    - an undeleted inode is evicted from memory

    - more than 24 hours have passed since the i-node was written to 
    disk.

nolazytime
    Do not use the lazytime feature.
<<snip>>

kjhambrick · 08-24-2016, 08:52 AM

To answer my own Q ...

Code:

mount -o'remount,nolazytime' /dev/sdX

does not work for now ...

Subject: nolazytime remount

Ted explains why in the 2nd message in the thread.

-- kjh

LQSlacker · 08-24-2016, 10:44 PM

Oh sheesh what the heck!

SUBSYSTEM=="block", ACTION=="add", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

Now this to me seems like the thing they'd do in Ubuntu, but in Slack!

I mean really, what happended here, with Slack as a distro for the experienced that do it themselves!

No wonder I was like what the heck is going on, no this was never in Slack before.

So what gave Pat or someone else the idea to do this, instead of leaving it alone and up to the end-user?

So instead of new udev rule, isn't the simpler way to go about this adding at the append line in lilo.conf;

elevator=deadline ?

rkelsen · 08-24-2016, 11:08 PM

Quote:

Originally Posted by kjhambrick

rkelson --

Yes, this has been educational for me too.

One thing about the link you pasted: it shows how to defragment an xfs filesystem.

I was referring to this bit: "XFS is among the recommended filesystems for use with SSD, supporting TRIM. In addition, XFS has had relatime as the default atime behaviour for a long time." Perhaps I should have been more specific.

It's good to know because XFS is what I've been using ever since Hans Reiser was convicted (up to which point I had been using reiserfs).

There is some irony, I guess, in that in all of those years I've never once defragmented an XFS filesystem. To be blunt, I didn't even know it was possible!

Wiser Slacker · 08-25-2016, 01:05 AM

on my first SSD i use

Code:

/dev/sda4        /                ext4        defaults,relatime       1   1

and do the fstrim once a year or so - just when i am thinking on it ...

it is working as the system disk to my raid server since 4 years now ...

bassmadrigal · 08-25-2016, 07:29 AM

Quote:

Originally Posted by LQSlacker

Oh sheesh what the heck!

SUBSYSTEM=="block", ACTION=="add", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

Now this to me seems like the thing they'd do in Ubuntu, but in Slack!

I mean really, what happended here, with Slack as a distro for the experienced that do it themselves!

No wonder I was like what the heck is going on, no this was never in Slack before.

So what gave Pat or someone else the idea to do this, instead of leaving it alone and up to the end-user?

This is from upstream. And as we know, Pat tries to not deviate from upstream. This came about when we switched from udev to eudev. If you check out the eudev source folder on your favorite mirror, there is a config directory that contains the two rules that Slackware adds to eudev, and this is not one of them. While I may prefer deadline over noop, I don't think the difference is enough to warrant Pat deviating from source. It is easy enough to override that in your /etc/udev/rules.d/ folder.

Quote:

Originally Posted by LQSlacker

So instead of new udev rule, isn't the simpler way to go about this adding at the append line in lilo.conf;

elevator=deadline ?

I don't think it would override a udev rule (but I haven't tested it). My thought behind it is that lilo would set it to deadline, then when udev gets loaded, it would override it (just like the default scheduler specified in the kernel). I asked kjhambrick to test this earlier, but maybe he missed it or hasn't gotten around to it.

Also, if you have regular HDDs, changing the scheduler in your bootloader would change it for your HDDs as well as your SSDs. Depending on your situation, deadline may not be preferable for spinning drives over CFQ. Overriding the udev rule will ensure it will only affect your SSD.

imitheos · 08-25-2016, 08:13 AM

Quote:

Originally Posted by LQSlacker

Oh sheesh what the heck!
So what gave Pat or someone else the idea to do this, instead of leaving it alone and up to the end-user?

As bassmadrigal said, this was an upstream choice. Here you can find the commit that made the change and you can read the justification for it.

kjhambrick · 08-25-2016, 09:40 AM

bassmadrigal --

Quote:

... I asked kjhambrick to test this earlier, but maybe he missed it or hasn't gotten around to it ...

Sorry ... I won't be able to test until this weekend when I can reboot and run thru the test cases.

-- kjh

bassmadrigal · 08-25-2016, 10:00 AM

Quote:

Originally Posted by kjhambrick

Sorry ... I won't be able to test until this weekend when I can reboot and run thru the test cases.

No worries... I hate rebooting my machine and tend to go many months in between reboots.

kjhambrick · 08-25-2016, 11:52 AM

Yes that, and I've also got looming software development deadlines for the 'real job'.

I've put off this weeks updates because of my deadlines and because I'll need to removepkg the 4.4.19 Packages I built myself from Pat's Kernel SlackBuilds.

I also built and installed 4.4.18 the same way the week before but I am now running my 'hand-rolled' 4.4.19 Packages.

I stupidly neglected to append an 'EXTRAVERSION' in the Kernel Makefile so the 4.4.19 kernel-modules Package I built will be overwritten by Pat's 4.4.19 kernel-modules-4.4.19 Package.

Don't want to do that to myself or to my running /lib/modules/4.4.19/ directory

It means I'll need to boot 4.4.18 ; removepkg 4.4.19 and then installpkg each of Pat's official 4.4.19 kernel-* Packages.

Lots to do in a methodical way before I start testing the udev rule

-- kjh( my Kernel SlackBuild Wrapper now sets the Makefile EXTRAVERSION= the same as BUILD= from the SlackBuild so this won't happen again (

at least until next time

)

LQSlacker · 08-26-2016, 05:06 PM

Ok Upstream, and I created the udev rule to make it deadline for my ssd...

And yes 'envelope' doesn't work in lilo.

Thanks all...

kjhambrick · 08-29-2016, 03:05 AM

LQSlacker --

Quote:

Ok Upstream, and I created the udev rule to make it deadline for my ssd...

And yes 'envelope' doesn't work in lilo.

Yes, referring to your other post, the udev rules implement an interesting syntax

And sorry ... what is envelope ?

Thanks.

-- kjh