Page 1 of 2 12 LastLast
Results 1 to 10 of 18

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

  1. #1
    Join Date
    Feb 2009
    Location
    USA
    Posts
    17

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

    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.

    Code:
    #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. #2
    Join Date
    Dec 2008
    Location
    FL, USA
    Posts
    4,112
    Blog Entries
    1

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

    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.
    Reg. Linux User 211409 *** multibooting since 1992
    Primary: 15.4, TW, 15.1 & 13.1 on Haswell @earthlink.net
    Secondary: eComStation (OS/2) &15.4 on i965P/Radeon
    Tertiary: Debian, Fedora, Mageia, more on Rocket Lake & older Intel, AMD, NVidia....

  3. #3
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    4,186
    Blog Entries
    5

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

    Quote Originally Posted by siftspam View Post
    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?
    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:
    Code:
    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:
    Code:
    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:~ #
    Code:
    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.
    i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), 5600X, 5700U (2022) openSUSE Tumbleweed, KDE Plasma
    See also Blogs > KeepItSimple

  4. #4
    Join Date
    Mar 2014
    Location
    Canary Island Lat. 27.994547-15.405127 Lon-160m sea level
    Posts
    348

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

    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. #5
    Join Date
    Mar 2014
    Location
    Canary Island Lat. 27.994547-15.405127 Lon-160m sea level
    Posts
    348

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

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

    Thanks .

    Best regards .

  6. #6
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    5,044

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

    Quote Originally Posted by siftspam View Post
    Is there some parameter that I can set so that fstrim will run just once a week and NOT at every power on/reboot?
    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:
    Code:
    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 …


    BTW: thanks for the tip – I need to update my systemd “fstrim” settings …

  7. #7
    Join Date
    Mar 2020
    Location
    São Leopoldo, RS, Brazil
    Posts
    430

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

    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/late...istration.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:

    Code:
    $ 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).
    openSUSE Tumbleweed

  8. #8
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    4,186
    Blog Entries
    5

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

    Quote Originally Posted by dcurtisfra View Post
    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:
    Code:
    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 …


    BTW: thanks for the tip – I need to update my systemd “fstrim” settings …
    Nope. btrfs periods are configured by sysconfig:
    Code:
    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:
    Code:
    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:~ #
    i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), 5600X, 5700U (2022) openSUSE Tumbleweed, KDE Plasma
    See also Blogs > KeepItSimple

  9. #9
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    5,044

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

    Quote Originally Posted by karlmistelberger View Post
    Nope. btrfs periods are configured by sysconfig:
    Thanks for the heads up but –
    Code:
     > 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_btrf...enance-refresh> and <https://en.opensuse.org/SDB:Disable_btrfsmaintenance>.
    Plus of course the Btrfs SDB: <https://en.opensuse.org/SDB:BTRFS>.

    Which package generates ‘/etc/sysconfig/btrfsmaintenance’ ?

  10. #10
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    4,186
    Blog Entries
    5

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

    Quote Originally Posted by dcurtisfra View Post
    Thanks for the heads up but –
    Code:
     > 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_btrf...enance-refresh> and <https://en.opensuse.org/SDBisable_btrfsmaintenance>.
    Plus of course the Btrfs SDB: <https://en.opensuse.org/SDB:BTRFS>.

    Which package generates ‘/etc/sysconfig/btrfsmaintenance’ ?
    Code:
    erlangen:~ # rpm -q --scripts btrfsmaintenance |grep PNAME 
        PNAME=btrfsmaintenance  
        SUBPNAME=  
        SYSC_TEMPLATE=/usr/share/fillup-templates/sysconfig.$PNAME$SUBPNAME
            SYSC_TEMPLATE=$TEMPLATE_DIR/sysconfig.$PNAME$SUBPNAME
                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:~ #
    i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), 5600X, 5700U (2022) openSUSE Tumbleweed, KDE Plasma
    See also Blogs > KeepItSimple

Page 1 of 2 12 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •