Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18

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

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

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

    Quote Originally Posted by karlmistelberger View Post
    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:...
    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!

  2. #12
    Join Date
    Feb 2009
    Location
    USA
    Posts
    17

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

    Quote Originally Posted by mikrios View Post
    Hello:
    I am not very in favor of installing TW on a laptop, because it changes version very frequently...
    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

  3. #13
    Join Date
    Feb 2009
    Location
    USA
    Posts
    17

    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 – ...

    • 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 …

    ...
    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. ;-)

  4. #14
    Join Date
    Jun 2008
    Location
    Ardrishaig, Argyll. Scotland UK - GMT/BST
    Posts
    36,879
    Blog Entries
    20

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

    Quote Originally Posted by siftspam View Post
    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
    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.
    Tumbleweed_KDE
    My Articles Was I any help? If yes: Click the star below

  5. #15
    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
    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
    This notebook runs Tumbleweed / KDE / btrfs only:
    Code:
    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:
    Code:
    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  SizeIdType
    /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.
    i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), 5600X, 5700U (2022) openSUSE Tumbleweed, KDE Plasma
    See also Blogs > KeepItSimple

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

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

    Quote Originally Posted by karlmistelberger View Post
    Code:
    erlangen:~ # rpm -q --scripts btrfsmaintenance |grep PNAME
    Ahhh – yes – but, another answer is:
    Code:
     > 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 …

  7. #17

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

    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


    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.

  8. #18
    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"?

    fstrim uses sane defaults on most distributions: https://fedoraproject.org/wiki/Chang...bleFSTrimTimer
    i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), 5600X, 5700U (2022) openSUSE Tumbleweed, KDE Plasma
    See also Blogs > KeepItSimple

Page 2 of 2 FirstFirst 12

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
  •