I have Leap 42.3 which was originally 42.1 and upgraded over the years. It was also originally installed on hdd on single btrfs partition. I did split it into two - /home went to a brand new mechanical hard drive and everything else, on a single btrfs partition on a new ssd.
Questions are:
Would noatime break something important? Right now i have it set noatime just for ‘/’ but all subvolumes still have relatime by default (based on /proc/mounts). I’m considering setting it for all subvolumes as well.
It seems openSUSE figured out that there is ssd in use, and i saw ssd settings/profile been activated during boot. I also have added ssd argument in fstab and all volumes and subvolumes have it too (again /proc/mounts). To be honest i have no clue what ‘ssd’ setting does and i couldnt find any information about it
is trim enabled by default? Maybe ‘ssd’ argument (see 2) above ) could take care of that?! systemctl status trim.timer reports following:
georgi@linux-f0hw:~> systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:fstrim
but then there is /etc/cron.weekly/btrfs-trim already
Schedulers are automatically set as they should for both ssd and the mechanical drive
I’ve been running my LEAP 42.3 KDE/Plasma without apparent problems. I’ve read it is not indicated to suppress time stamps if you are running an e-mail server, for example.
IFAIK it sets up garbage collection (fstrim) and, in the case of Windows, disable defrag and possibly sets a fixed size for it’s swap file.
Anyway, in this box I see:
:~> systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; **enabled**; vendor preset: enabled)
Active: active (waiting) since Qua 2018-04-11 12:47:17 -03; 4 days ago
Docs: man:fstrim
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
“ssd” option changes space allocation algorithm by making btrfs prefer allocating new (larger) chunks over filling existing partial chunks. You may want to look in btrfs mailing list archives, there were several discussions on this topic over last year. It is believed that with modern hardware ssd option is hardly needed and may actually cause other problems (like premature out of space condition).
is trim enabled by default? Maybe ‘ssd’ argument (see 2) above ) could take care of that?
No, “ssd” option does not affect trim. Although one can argue that “ssd” should be accompanied by trim to actually achieve its goal.
Source please? And, please tell me it’s not this computertips site.
I asked Greg KH years ago re. the matter of trimming. His response was to stick to the defaults, as provided by the distributions.
georgi@linux-f0hw:~> systemctl status fstrim.timer
**●** fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
Active: **active (waiting)** since Mon 2018-04-23 04:09:56 EEST; 13min ago
Docs: man:fstrim
I guess its up and active but how do i know if trimming have already been executed, or how long would it take. If its a process that takes time - what happens if i go and reboot the system in the middle of it?
The trimming process last few seconds.
You can see if it works with journalctl, weekly.
If you are not sure about fstrim.service you can trim weekly but manually.
georgi@linux-f0hw:~> systemctl start fstrim.service
georgi@linux-f0hw:~> journalctl -u fstrim
Hint: You are currently not seeing messages from other users and the system.
Users in the 'systemd-journal' group can see all messages. Pass -q to
turn off this notice.
-- No entries --
georgi@linux-f0hw:~> lsblk --discard
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda 0 512B 2G 0
├─sda1 0 512B 2G 0
└─sda2 0 512B 2G 0
sdb 0 0B 0B 0
└─sdb1 0 0B 0B 0
sdc 0 0B 0B 0
├─sdc1 0 0B 0B 0
├─sdc2 0 0B 0B 0
├─sdc3 0 0B 0B 0
├─sdc4 0 0B 0B 0
└─sdc5 0 0B 0B 0
georgi@linux-f0hw:~> lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 /boot/grub2/i386-pc
└─sda2 [SWAP]
sdb
└─sdb1 /home
sdc
├─sdc1
├─sdc2
├─sdc3
├─sdc4
└─sdc5
When starting trim service it just waits like 5 sec and then return to prompt with no output for the executed command
Its Transcend 230S 128GB
I also noticed that first launch and search in alt+tab pop-up box was instant fast the first week, and now its kind of back to lagging in its reaction as it was with my old mechanical hdd. Thats just the first run then its its fine after that.