SSD and file system tunning in current Kubuntu

[Caesar]

So I'm going to install Kubuntu on SSD drive (Samsung PM961 MZVLW256HEHP M.2 NVMe PCIe Gen3 x4), and I wonder if the tips for better performance of Ext4 file system as for the drive itself given here are still up-to-date? Anyone tried those tips?

[claydoh]

That is really old info. I believe all these steps are taken care of already nowadays, are built-in, or are no longer needed, some 7 years since that page was written.
You don't need to do anything special at all, really. I never have.

[jglen490]

I know for certain that fstrim was installed and set up in 18.04 and in 16.04 without doing anything. It's possible that fstrim was done before then, too. Up until this past weekend I've not had an SSD on my machine, so it was being installed without regard to having an SSD.

You can look at and probably change the timing if you want, but don't be too worried about it.

[Caesar]

And what about journaling and reduction in writing to the SSD by using tmpfs? Are those worth giving a try?

[claydoh]

And what about journaling and reduction in writing to the SSD by using tmpfs? Are those worth giving a try?

This is already set up for you when you install.

[jglen490]

Straight out of the box - or at least the USB drive:

john@john-Desktop:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            7.8G     0  7.8G   0% /dev
tmpfs           1.6G  1.5M  1.6G   1% /run
/dev/sda2       219G  6.6G  201G   4% /
tmpfs           7.8G   35M  7.8G   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/sdb1       293G  100G  178G  36% /home
/dev/sda1       380M  6.1M  374M   2% /boot/efi
tmpfs           1.6G     0  1.6G   0% /run/user/119
tmpfs           1.6G   20K  1.6G   1% /run/user/1000

[Caesar]

My /etc/fstab

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/nvme0n1p1 during installation
UUID=1c340273-6cc2-4068-b7c8-0593b18a9927 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/nvme1n1p2 during installation
UUID=82B3-DE5D  /boot/efi       vfat    umask=0077      0       1
/swapfile                                 none            swap    sw              0       0

I'm still not sure if everything is set up out of the box. Even in Windows 10 it isn't.

[claydoh]

the tmpfs won't be in the fstab, as this is a virtual file system, not a physical one, and is controlled by the kernel, not the fstab.
If you type the command jglen490 used, you will see all theses listed.

[Caesar]

I know that. What I've meant is what about disabling journaling on ext4 and enabling TRIM and disabling excessive file metadata with options like

UUID=a6ed37e6-ee89-4621-bd35-a5e9466275ac  /     ext4    noatime,discard,errors=remount-ro 0       1

[claydoh]

Because they are the defaults, and don't need to be set in the fstab specifically, and/or are run as periodic services via systemd


fstrim has been automatically since at least 14.10

claydoh@claydoh-ideapad:~$ systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Thu 2019-05-23 18:30:13 EDT; 1 weeks 3 days ago
  Trigger: Mon 2019-06-10 00:00:00 EDT; 6 days left
     Docs: man:fstrim

May 23 18:30:13 claydoh-ideapad systemd[1]: Started Discard unused blocks once a week.

I have no idea why anyone would disable journaling altogether, but it os of course possible to do if one wants.

look at the output of the mount command to see more details about the mount options used, as opposed to what the fstab says.

relatime is the default, and that function has been kept up with the times, so it is , as far as I can tell, the safe and correct one to use., though one can try noatime of they want to slightly reduce writes over relatime, but it some software needs the information left out if you use it over the default. Your choice there.

Again, distros (and the kernel itself) set these things up with sane defaults already.
Here is a more up to date info page about this:
https://wiki.debian.org/SSDOptimization
or the one from Arch's wiki. Both are good,. but if you dig a tiny bit, you will find all of these are being done already.



And there is this:
https://www.reddit.com/r/linuxquesti...ux_to_protect/

Ubuntu, and most distros have extremely sane defaults for SSDs, though of course anyone is free to change these to less sane ones
I recommend doing more research, as I am just just some dude writing stuff on the internet, after all. But do look at more MUCH more recent info than 2012 .
My personal opinion is that the gains made by trying out optimizations won't save enough life, and modern nvme drives specifically are overprovisioned to give better life as well as speed.

[jglen490]

I think with the present state of things, there is very little to worry about WRT SSD drives. Micromanaging will probably gain something equally microscopic. I have no intention of worrying about my SSD. Of course, mine's a cheap Kingston and may not last very long, but if it looks promising to have an SSD with stock settings in Kubuntu, I'm not going to worry about it. If this one does fail soon, I have its twin as a spare setting in my desk drawer.

[claydoh]

I think with the present state of things, there is very little to worry about WRT SSD drives. Micromanaging will probably gain something equally microscopic. I have no intention of worrying about my SSD. Of course, mine's a cheap Kingston and may not last very long, but if it looks promising to have an SSD with stock settings in Kubuntu, I'm not going to worry about it. If this one does fail soon, I have its twin as a spare setting in my desk drawer.

Agreed. I am still waiting for my first SSD to die. Even the 5 year old one I no longer have is still chugging along.

[Caesar]

According to Arch Linux wiki (IMO the best Linux wiki)

The process to change I/O scheduler, depending on whether the disk is rotating or not can be automated and persist across reboots. For example the udev rule below sets the scheduler to none for NVMe, mq-deadline for SSD/eMMC, and bfq for rotational drives:

/etc/udev/rules.d/60-ioschedulers.rules
# set scheduler for NVMe
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="none"
# set scheduler for SSD and eMMC
ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
# set scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"

In my kubuntu I have the following scheduler

achilleus@Linux:~$ cat /sys/block/sda/queue/scheduler
[mq-deadline] none

AFAIK the scheduler-name that has square brackets around it, is the active scheduler. Is it worth changing?

Also I went for that advice, as I have 32GB orf RAM and mostly only 3GB is being used.

To reduce writing to the SSD, we will be using tmpfs (i.e. RAM-disk) to store the system cache and temp directory. You can use the same for logs /var/log, however, I like to keep my logs between reboots so I will use the regular disk for that. Add the following lines to the /etc/fstab.

tmpfs   /tmp       tmpfs   defaults,noatime,mode=1777   0  0
tmpfs   /var/spool tmpfs   defaults,noatime,mode=1777   0  0
tmpfs   /var/tmp   tmpfs   defaults,noatime,mode=1777   0  0

The TRIM is enabled out-of-the-box in my system [non-zero values of DISC-GRAN (discard granularity) and DISC-MAX (discard max bytes) indicate TRIM support]

achilleus@Linux:~$ lsblk --discard
NAME        DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                0        0B       0B         0
├─sda1             0        0B       0B         0
└─sda2             0        0B       0B         0
nvme0n1            0      512B       2T         0
├─nvme0n1p1        0      512B       2T         0
├─nvme0n1p2        0      512B       2T         0
├─nvme0n1p3        0      512B       2T         0
└─nvme0n1p4        0      512B       2T         0
nvme1n1            0      512B       2T         0
└─nvme1n1p1        0      512B       2T         0

I'm leaving journaling for ext4.

[claydoh]

But Ubuntu already takes care of this on a per-device basis:

here is my nvme drive

$ cat /sys/block/nvme0n1/queue/scheduler
 [none]

and my spinning drive:

$ cat /sys/block/sda/queue/scheduler 
noop deadline [cfq]

Note this is on an 18.04 based system

[claydoh]

And some recent scheduler benchmarks, if you want to try others:

https://www.phoronix.com/scan.php?pa...io-sched&num=1