new install, fstrim.timer running more than the configured "once a week"?

English Hardware
#1

Hi,

I installed TW on a new laptop with an NVMe SSD as the internal drive. Installation detected the SSD and configured fstrim.timer to run once a week. I thought that was cool. But, when I checked journalctl, I found that fstrim is actually running more often than once a week (see CODE block below).

I am guessing that fstrim.timer is running every time I power on (or reboot) the laptop. Is that right? If so, is that a good idea? I am new to NVMe and I do not want to cause unnecessary wear just because I power off the laptop at night or reboot often when testing. Is there some parameter that I can set so that fstrim will run just once a week and NOT at every power on/reboot?

Thanks.

#sudo journalctl -u fstrim.timer 
Aug 08 01:34:14 laptop.test systemd[1]: Started Discard unused blocks once a week.
Aug 08 04:35:05 laptop.test systemd[1]: fstrim.timer: Deactivated successfully.
Aug 08 04:35:05 laptop.test systemd[1]: Stopped Discard unused blocks once a week.
-- Boot 4af963e71de544f3acb913a6855936c9 --
Aug 08 18:57:16 laptop.test systemd[1]: Started Discard unused blocks once a week.
Aug 09 04:10:13 laptop.test systemd[1]: fstrim.timer: Deactivated successfully.
Aug 09 04:10:13 laptop.test systemd[1]: Stopped Discard unused blocks once a week.
-- Boot 4f43953df7b042c4a93a91a9cb8ca6aa --
Aug 09 20:15:13 laptop.test systemd[1]: Started Discard unused blocks once a week.
Aug 11 01:51:14 laptop.test systemd[1]: fstrim.timer: Deactivated successfully.
Aug 11 01:51:14 laptop.test systemd[1]: Stopped Discard unused blocks once a week.
-- Boot c80c463bb9304aa784f06d141d7c6156 --
Aug 11 11:29:41 laptop.test systemd[1]: Started Discard unused blocks once a week.

#systemctl list-timers
NEXT                        LEFT          LAST                        PASSED     UNIT                         ACTIVATES
Fri 2022-08-12 00:00:00 PDT 3h 17min left Thu 2022-08-11 00:00:06 PDT 20h ago    logrotate.timer              logrotate.service
Fri 2022-08-12 00:00:00 PDT 3h 17min left Thu 2022-08-11 00:00:06 PDT 20h ago    man-db.timer                 man-db.service
Fri 2022-08-12 00:03:52 PDT 3h 21min left Thu 2022-08-11 01:27:06 PDT 19h ago    backup-rpmdb.timer           backup-rpmdb.service
Fri 2022-08-12 01:07:52 PDT 4h 25min left Thu 2022-08-11 01:38:34 PDT 19h ago    backup-sysconfig.timer       backup-sysconfig.service
Fri 2022-08-12 01:26:15 PDT 4h 44min left Thu 2022-08-11 00:44:06 PDT 19h ago    check-battery.timer          check-battery.service
Fri 2022-08-12 11:44:13 PDT 15h left      Thu 2022-08-11 11:44:13 PDT 8h ago     systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2022-08-15 01:39:21 PDT 3 days left   Mon 2022-08-08 01:34:14 PDT 3 days ago fstrim.timer                 fstrim.service

7 timers listed.

#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 Thu 2022-08-11 11:29:41 PDT; 8h ago
      Until: Thu 2022-08-11 11:29:41 PDT; 8h ago
    Trigger: Mon 2022-08-15 01:39:21 PDT; 3 days left
   Triggers: ● fstrim.service
       Docs: man:fstrim

#lspci | grep SSD
05:00.0 Non-Volatile memory controller: Sandisk Corp WD Black SN750 / PC SN730 NVMe SSD
#2

I don’t know what the “Until” line is about, but it’s clear to me fstrim last ran 3.x days ago and is scheduled to run next after 3.x more days.

#3

There are two units: a timer and a service. The timer starts on boot, but doesn’t run any executable of its own. It starts the associated service as scheduled:

**erlangen:~ #** journalctl -q -u backup-home.timer -g Started        
Aug 10 13:35:41 erlangen systemd[1]: Started Backup of /home. 
Aug 11 05:27:51 erlangen systemd[1]: Started Backup of /home. 
Aug 11 09:36:12 erlangen systemd[1]: Started Backup of /home. 
Aug 11 21:04:21 erlangen systemd[1]: Started Backup of /home. 
**erlangen:~ #**

erlangen was booted three times yesterday and is still up today. On each boot timer was started according to install directives:

**erlangen:~ #** systemctl cat backup-home.timer  
**# /etc/systemd/system/backup-home.timer**
[Unit] 
Description=Backup of /home 
After=local-fs.target 

[Timer] 
OnCalendar=daily 
AccuracySec=1m 
Persistent=true 

[Install] 
WantedBy=timers.target 
**erlangen:~ #**

**erlangen:~ #** journalctl -q -u backup-home.service -g Started      
Aug 10 13:36:27 erlangen systemd[1]: Started Backup /home. 
Aug 11 05:47:01 erlangen systemd[1]: Started Backup /home. 
Aug 12 04:37:31 erlangen systemd[1]: Started Backup /home. 
**erlangen:~ #**

Service scheduled daily was started once yesterday and once today.

#4

Hello:

I am not very in favor of installing TW on a laptop, because it changes version very frequently (it can cause problems if you have other operating systems, although I do not know for sure because I do not have TW on a laptop, I use Leap, it is more stable in that type of equipment).

The fstrim function is that, of the 2 ways that there are for the trim, you use the one that is executed in real time and at all times (although it may be controlled by systemd at startup or using cron) and the other, which is executed from time to time it is discard , the latter in my opinion is the one that should be used.

Now, if you use btrfs, the ssd option, I don’t know if it includes discard, at least it recognizes ssds and configures them in many things.

My opinion is to use Leap, and discard on a laptop, kernel changes involve changes in the loader, it almost always goes well, but I don’t know if it can fail, on the other hand I have had TW for more than 4 years and with hardly a failure , but rn a desktop computer.

I could be wrong, mine is just an opinion and sorry if there is any mistake in the sentences, I use a translator and I don’t know how it comes out so that they understand me.

Thank you and a very cordial greeting

#5

Hello: Is it a systemd service or is it a cron service?

Thanks .

Best regards .

#6

What you have to do is, to override the distribution’s default systemd settings –

  • The documentation is difficult – there is help on the Internet – and, a man page → systemd.unit(5) → the thing to look for is “dropin”.
    The directory ‘/etc/systemd/system’ is also needed.

The quick answer is –

  • Copy the file ‘/usr/lib/systemd/system/fstrim.timer’ to ‘/etc/systemd/system/’ and then edit the file you’ve placed below ‘/etc/’ where, package patches and updates will not tamper with it – in contrast to what happens with the files located below ‘/usr/’ …

My systemd ‘/etc/’ “fstrim” setting is as follows:

OnCalendar=monthly
  • Please be aware that, you’ll need to occasionally review the file below ‘/etc/’ because, patches may well change some of the other settings in the file located below ‘/usr/’ …
    You may have to modify your settings located below ‘/etc/’ to keep your local preferences synchronised to what’s happening elsewhere in the distribution …

[HR][/HR]BTW: thanks for the tip – I need to update my systemd “fstrim” settings … :shame:

#7

Since kernel 5.6 btrfs supports an async real-time discard:

discard, discard=sync, discard=async, nodiscard
(default: off, async support since: 5.6)
Enable discarding of freed file blocks. This is useful for SSD devices, thinly provisioned LUNs, or virtual machine images; however, every storage layer must support discard for it to work.

In the synchronous mode (sync or without option value), lack of asynchronous queued TRIM on the backing device TRIM can severely degrade performance, because a synchronous TRIM operation will be attempted instead. Queued TRIM requires newer than SATA revision 3.1 chipsets and devices.

The asynchronous mode (async) gathers extents in larger chunks before sending them to the devices for TRIM. The overhead and performance impact should be negligible compared to the previous mode and it’s supposed to be the preferred mode if needed.

If it is not necessary to immediately discard freed blocks, then the fstrim tool can be used to discard all free blocks in a batch. Scheduling a TRIM during a period of low system activity will prevent latent interference with the performance of other operations. Also, a device may ignore the TRIM command if the range is too small, so running a batch discard has a greater probability of actually discarding the blocks.

Source: https://btrfs.readthedocs.io/en/latest/Administration.html

So mounting btrfs with discard=async and but then configuring fstrim.timer to activate fstrim.service monthly should be a balanced alternative.

To verify how many blocks were discarded since boot up install and run iostat:


$ iostat -m
...
Device             tps    MB_read/s    MB_wrtn/s    MB_dscd/s    MB_read    MB_wrtn    MB_dscd
nvme0n1           9.46         0.11         0.34         0.00      37566     115098          0
sda               0.00         0.00         0.00         0.00          3          0          0

Watch for the MB_dscd column, no discards were issued since 3 days ago (no discard mount option, weekly fstrim.timer).

#8

Nope. btrfs periods are configured by sysconfig:

**erlangen:~ #** grep PERIOD /etc/sysconfig/btrfsmaintenance 
BTRFS_DEFRAG_**PERIOD**="none" 
BTRFS_BALANCE_**PERIOD**="weekly" 
BTRFS_SCRUB_**PERIOD**="monthly" 
BTRFS_TRIM_**PERIOD**="none" 
**erlangen:~ #**

Use “systemctl edit fstrim.timer” to configure this unit. It will create a proper drop-in file:

**erlangen:~ #** systemctl cat fstrim.timer  
**# /usr/lib/systemd/system/fstrim.timer**
[Unit] 
Description=Discard unused blocks once a week 
Documentation=man:fstrim 
ConditionVirtualization=!container 
ConditionPathExists=!/etc/initrd-release 

[Timer] 
OnCalendar=weekly 
AccuracySec=1h 
Persistent=true 
RandomizedDelaySec=6000 

[Install] 
WantedBy=timers.target 

**# /etc/systemd/system/fstrim.timer.d/override.conf**
**OnCalendar=monthly **
**erlangen:~ #**
#9

Thanks for the heads up but –


 > rpm --query --whatprovides /etc/sysconfig/btrfsmaintenance
file /etc/sysconfig/btrfsmaintenance is not owned by any package
 >

There are these SDB articles: <https://en.opensuse.org/SDB:Fix_btrfsmaintenance-refresh> and <https://en.opensuse.org/SDB:Disable_btrfsmaintenance>.
Plus of course the Btrfs SDB: <https://en.opensuse.org/SDB:BTRFS>.
[HR][/HR]Which package generates ‘/etc/sysconfig/btrfsmaintenance’ ?

#10 
**erlangen:~ #** rpm -q --scripts btrfsmaintenance |grep PNAME 
    **PNAME**=btrfsmaintenance  
    SUB**PNAME**=  
    SYSC_TEMPLATE=/usr/share/fillup-templates/sysconfig.$**PNAME**$SUB**PNAME**
        SYSC_TEMPLATE=$TEMPLATE_DIR/sysconfig.$**PNAME**$SUB**PNAME**
            echo "Updating /etc/sysconfig/$SD_NAME$**PNAME** ..."  
            touch /etc/sysconfig/$SD_NAME$**PNAME**
            /bin/fillup -q /etc/sysconfig/$SD_NAME$**PNAME** $SYSC_TEMPLATE  
        echo "/etc/sysconfig/$**PNAME** and $TEMPLATE_DIR/sysconfig.$**PNAME** and"  
**erlangen:~ #**
#11

Ahhh… Your description makes sense. The timer unit is (periodically?) waking up to check if it is time to run the service. I guess I was thrown off by all the timer journalctl log messages and the absence of any fstimer.service log messages. I will wait for the timer to run the service and then see what the logs say after that.

Thanks for your response!

#12

Thank you for your concern re: TW on a laptop. I too usually install Leap. Unfortunately, the kernel in Leap 15.4 does not support my laptop’s wifi hardware (MEDIATEK MT7922). I tried many distributions and found that only Manjaro and Tumbleweed offered kernels (5.18+) that support this hardware. Even so, I am still waiting for kernel support for bluetooth on the MEDIATEK MT7922.

So far, the frequent updates haven’t been a problem. Once a stable Leap distribution supports my hardware, I may switch back to Leap.

Best Regards

#13

Thank you for the detailed information and the “warning” about the need for manual “synchronization” checks. This might explain why my past attempts to customize systemd had problems. :wink:

#14

Installing leap and then using the Kernel Head repo is always an option too

FYI I have been using TW now on my laptop for some years.

#15

This notebook runs Tumbleweed / KDE / btrfs only:

**notebook:~ #** inxi -zFm 
**System:**
  **Kernel:** 5.19.0-1-default **arch:** x86_64 **bits:** 64 **Console:** pty pts/1 
    **Distro:** openSUSE Tumbleweed 20220811 
**Machine:**
  **Type:** Laptop **System:** HP **product:** HP Laptop 15-da0xxx 
    **v:** Type1ProductConfigId **serial:** <filter> 
  **Mobo:** HP **model:** 84A6 **v:** 80.24 **serial:** <filter> **UEFI:** Insyde **v:** F.02 
    **date:** 05/24/2018 
**Battery:**
  **ID-1:** BAT1 **charge:** 33.6 Wh (91.8%) **condition:** 36.6/41.9 Wh (87.4%) 
    **volts:** 12.0 **min:** 11.6 
**Memory:**
  **RAM:****total:** 7.68 GiB **used:** 2.59 GiB (33.8%) 
  **Array-1:****capacity:** 32 GiB **slots:** 2 **EC:** None 
  **Device-1:** Bottom-slot 1(left) **type:** DDR4 **size:** 8 GiB **speed:** 2400 MT/s 
  **Device-2:** Bottom-slot 2(right) **type:** no module installed 
**CPU:**
  **Info:** quad core **model:** Intel Core i5-8250U **bits:** 64 **type:** MT MCP **cache:**
    **L2:** 1024 KiB 
  **Speed (MHz):****avg:** 1675 **min/max:** 400/3400 **cores:****1:** 1800 **2:** 1800 **3:** 1800 
    **4:** 1800 **5:** 1800 **6:** 800 **7:** 1800 **8:** 1800 
**Graphics:**
  **Device-1:** Intel UHD Graphics 620 **driver:** i915 **v:** kernel 
  **Device-2:** Lite-On HP Webcam **type:** USB **driver:** uvcvideo 
  **Display:** x11 **server:** X.Org **v:** 21.1.4 **with:** Xwayland **v:** 22.1.3 **driver:****X:**
    **loaded:** modesetting **unloaded:** fbdev,vesa **gpu:** i915 
    **resolution:** 1368x768~60Hz 
  **OpenGL:****renderer:** Mesa Intel UHD Graphics 620 (KBL GT2) 
    **v:** 4.6 Mesa 22.1.4 
**Audio:**
  **Device-1:** Intel Sunrise Point-LP HD Audio **driver:** snd_hda_intel 
  **Sound Server-1:** ALSA **v:** k5.19.0-1-default **running:** yes 
  **Sound Server-2:** PulseAudio **v:** 16.1 **running:** yes 
  **Sound Server-3:** PipeWire **v:** 0.3.56 **running:** yes 
**Network:**
  **Device-1:** Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
    **driver:** r8169 
  **IF:** eno1 **state:** up **speed:** 100 Mbps **duplex:** full **mac:** <filter> 
  **Device-2:** Realtek RTL8821CE 802.11ac PCIe Wireless Network Adapter 
    **driver:** rtw_8821ce 
  **IF:** wlo1 **state:** down **mac:** <filter> 
**Bluetooth:**
  **Device-1:** Realtek Bluetooth 4.2 Adapter **type:** USB **driver:** btusb 
  **Report:** rfkill **ID:** hci0 **state:** up **address:** see --recommends 
**RAID:**
  **Hardware-1:** Intel 82801 Mobile SATA Controller [RAID mode] **driver:** ahci 
**Drives:**
  **Local Storage:****total:** 238.47 GiB **used:** 25.16 GiB (10.6%) 
  **ID-1:** /dev/nvme0n1 **vendor:** Toshiba **model:** N/A **size:** 238.47 GiB 
**Partition:**
  **ID-1:** / **size:** 238.38 GiB **used:** 25.16 GiB (10.6%) **fs:** btrfs 
    **dev:** /dev/nvme0n1p2 
  **ID-2:** /boot/efi **size:** 99.8 MiB **used:** 1.8 MiB (1.8%) **fs:** vfat 
    **dev:** /dev/nvme0n1p1 
  **ID-3:** /home **size:** 238.38 GiB **used:** 25.16 GiB (10.6%) **fs:** btrfs 
    **dev:** /dev/nvme0n1p2 
  **ID-4:** /opt **size:** 238.38 GiB **used:** 25.16 GiB (10.6%) **fs:** btrfs 
    **dev:** /dev/nvme0n1p2 
  **ID-5:** /var **size:** 238.38 GiB **used:** 25.16 GiB (10.6%) **fs:** btrfs 
    **dev:** /dev/nvme0n1p2 
**Swap:**
  **Alert:** No swap data was found. 
**Sensors:**
  **System Temperatures:****cpu:** 36.0 C **pch:** 32.0 C **mobo:** N/A 
  **Fan Speeds (RPM):** N/A 
**Info:**
  **Processes:** 262 **Uptime:** 0h 10m **Shell:** Bash **inxi:** 3.3.19 
**notebook:~ #**

Partitioning:

**notebook:~ #** fdisk -l 
**Disk /dev/nvme0n1: 238.47 GiB, 256060514304 bytes, 500118192 sectors**
Disk model: KBG30ZMV256G TOSHIBA                     
Units: sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 512 bytes 
I/O size (minimum/optimal): 512 bytes / 512 bytes 
Disklabel type: dos 
Disk identifier: 0xb499f273 

**Device        ****Boot**** Start****      End****  Sectors****  Size****Id****Type**
/dev/nvme0n1p1        2048    206847    204800   100M ef EFI (FAT-12/16/32) 
/dev/nvme0n1p2      206848 500118191 499911344 238.4G 83 Linux 
**notebook:~ #** lsblk -f 
NAME        FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS 
sr0                                                                                 
nvme0n1                                                                             
├─nvme0n1p1 vfat   FAT16       539A-82CF                                98M     2% /boot/efi 
└─nvme0n1p2 btrfs              802508d7-60ac-43e1-a4eb-c93826ec37c2    212G    10% /var 
                                                                                   /usr/local 
                                                                                   /srv 
                                                                                   /root 
                                                                                   /opt 
                                                                                   /home 
                                                                                   /boot/grub2/x86_64-efi 
                                                                                   /boot/grub2/i386-pc 
                                                                                   /.snapshots 
                                                                                   / 
**notebook:~ #**

For the sake of easy maintenance I canonify all installations on the hardware listed in the signature. I never considered undoing any of the steps made since 2016.

#16

Ahhh – yes – but, another answer is:


 > rpm --query --whatprovides /usr/share/fillup-templates/sysconfig.btrfsmaintenance
btrfsmaintenance-0.4.2-3.3.1.noarch
 >

Which begs the thought –

  • One of the SUSE/openSUSE features is, that “sysconfig” parameters are preferred over system application (such as “systemd”) administration settings in ‘/etc/ … ’ files because, one can then administer the settings via YaST or, other system administration tools – simply search for “btrfs” in the Sysconfig editor.
  • And, the settings will (maybe
    ) be preserved from patches and updates because, of the “new/saved” mechanism in the patching/update scripts – and, “rpmconfigcheck” will allow checking for any changes made …
#17

Hello Tumbleweed on a lapatop guy (or gall),

Eeek! I ran tw on my desktop for two days. I was happy enough with it until an update left me unable to boot into anything … I’m back on leap :slight_smile:

I just did a bunch of research on trim. Until a couple of weeks ago, I didn’t know it even existed. After a bunch of reading and testing and reading and testing … I don’t think it matters significantly whether you run trim continuously (as with the “discard” mount option, which is the ONLY way to have trim run on mdraid devices), daily, weekly, monthly, or not at all. I ran a number of performance tests on my home directory which would not have been trimmed for well over a year (as trim is probably invoked by fsck.ext4, so whenever I created the file system), versus my home directory after a manual trim (which trimmed a bunch of blocks), versus trim running trim continuously via the “discard” mount option. I found no appreciable differences in either read or write speeds across multiple tests. All my testing was done with fio, expect one, in which I used dd to simply read a file, about 10 GB.

Another thing you should be aware of if you still care to think about it at all, luks will pass trim requests only if it is configured to allow it. With luks2, one would need to run “cryptsetup --refresh --persistent --allow-discards /dev/<UNDERLYING_BLOCK_DEVICE>”. This will write the option to the luks2 header and will not need to be invoked again. With luks1, a discard option would have to be provided in /etc/crypttab in order to make the change “permanent”.

I like the discard mount option because deleted files are really deleted. Does this enhance my security? Probably not :). Of course, the opposite is true if you are the occasional user of photorec and LIKE to be able to recover deleted files. In that case, don’t use the “discard” mount option.

I strongly suspect that manual evocation of trim/deallocate commands by software is an obsolete holdover from a time not so long ago when solid state storage was much more expensive and temperamental that it is today. In all my scouring of the internet, I did not find anything to substantiate the claim that “trim” extends the life of devices. My own performance testing convinced me that the differences, if any, would certainly not be noticeable in a single user desktop type environment.

My final thought, why not just “systemctl disable fstrim.timer” or “systemctl mask fstrim.timer” ??? Seems simple enough … but I honestly don’t think it matters enough to worry about.

#18

fstrim uses sane defaults on most distributions: https://fedoraproject.org/wiki/Changes/EnableFSTrimTimer