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?
Announcement
Collapse
No announcement yet.
SSD and file system tunning in current Kubuntu
Collapse
This topic is closed.
X
X
-
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.
- Top
- Bottom
-
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.The next brick house on the left
Intel i7 11th Gen | 16GB | 1TB | KDE Plasma 5.27.11| Kubuntu 24.04 | 6.8.0-31-generic
- Top
- Bottom
Comment
-
-
Straight out of the box - or at least the USB drive:Code: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
The next brick house on the left
Intel i7 11th Gen | 16GB | 1TB | KDE Plasma 5.27.11| Kubuntu 24.04 | 6.8.0-31-generic
- Top
- Bottom
Comment
-
My /etc/fstab
Code:# /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
- Top
- Bottom
Comment
-
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.
- Top
- Bottom
Comment
-
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
Code:UUID=a6ed37e6-ee89-4621-bd35-a5e9466275ac / ext4 noatime,discard,errors=remount-ro 0 1
- Top
- Bottom
Comment
-
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
Code: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.
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.
- Top
- Bottom
Comment
-
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.The next brick house on the left
Intel i7 11th Gen | 16GB | 1TB | KDE Plasma 5.27.11| Kubuntu 24.04 | 6.8.0-31-generic
- Top
- Bottom
Comment
-
Originally posted by jglen490 View PostI 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.
- Top
- Bottom
Comment
-
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:
Code:/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"
Code:achilleus@Linux:~$ cat /sys/block/sda/queue/scheduler [mq-deadline] none
Also I went for that advice, as I have 32GB orf RAM and mostly only 3GB is being used.
Code: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
Code: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
Last edited by Caesar; Jun 08, 2019, 12:18 PM.
- Top
- Bottom
Comment
-
But Ubuntu already takes care of this on a per-device basis:
here is my nvme drive
Code:$ cat /sys/block/nvme0n1/queue/scheduler [none]
Code:$ cat /sys/block/sda/queue/scheduler noop deadline [cfq]
Last edited by claydoh; Jun 08, 2019, 12:29 PM.
- Top
- Bottom
Comment
-
And some recent scheduler benchmarks, if you want to try others:
https://www.phoronix.com/scan.php?pa...io-sched&num=1
- Top
- Bottom
Comment
Comment