Trim - Btrfs and Ext4

Hello all. Installed Garuda (Xfce) yesterday (only five years late :wink: ).

I have two SSDs in my laptop

  • 256GB where I have installed Garuda using LUKS encryption and the formatting defaults so it consists of a FAT32 /boot/efi and a Btrfs /
  • 4TB already formatted as LUKS encrypted EXT4, mounted as /mnt/Data (mostly media files, but also an hourly rsync backup of most of /home)

The output of systemctl status btrfs-trim.timer is:

● btrfs-trim.timer - Discard unused blocks on a mounted filesystem
     Loaded: loaded (/usr/lib/systemd/system/btrfs-trim.timer; enabled; preset: disabled)
     Active: active (waiting) since Fri 2025-03-21 09:35:21 GMT; 1h 23min ago
 Invocation: 9b6f13dcf454433ba361053fa73ba5fb
    Trigger: Tue 2025-04-01 00:00:00 BST; 1 week 3 days left
   Triggers: ● btrfs-trim.service
       Docs: man:fstrim

and so I am assuming that btrfs-trim will run on the / Btrfs partition on the 1st of every month.

For the 4TB SSD, I have followed the instructions at dm-crypt/Specialties - ArchWiki and the output of sudo cryptsetup luksDump /dev/sda | grep Flags is allow-discards. I have also enabled fstrim-timer and the output of systemctl status fstrim.timer is

● fstrim.timer - Discard unused filesystem blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; preset: disabled)
     Active: active (waiting) since Fri 2025-03-21 10:34:28 GMT; 25min ago
 Invocation: da3f612bb4c84f09aa0e0879c9a69066
    Trigger: Mon 2025-03-24 00:50:45 GMT; 2 days left
   Triggers: ● fstrim.service
       Docs: man:fstrim

so I am assuming that fstrim will run on the 4TB SSD weekly on a Monday.

I have two questions:

  1. Are my assumptions above correct that btrfs-trim will run on the 1st of the month only on the / btrfs partition, and that fstrimwill run weekly on a Monday only on the 4TB SSD?
  2. What happens when the 1st of the month is a Monday (September is the next one)? I notice a time offset between the two triggers above, but my laptop is highly unlikely to be on at these times. Would btrfs-trim and fstrim both run on booting my laptop on Mon 1st Sept, and would there be any conflicts between them?

I hope the above makes sense.

garuda-inxi
System:
  Kernel: 6.13.7-arch1-1 arch: x86_64 bits: 64 compiler: gcc v: 14.2.1
    clocksource: tsc avail: hpet,acpi_pm
    parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux
    root=UUID=f3aaf53c-eae0-4902-9e91-266d214a3fe7 rw rootflags=subvol=@
    quiet rd.luks.uuid=61270517-44f2-4f88-8fe2-64c24eeb9c41 loglevel=3
    ibt=off
  Desktop: Xfce v: 4.20.1 tk: Gtk v: 3.24.48 wm: xfwm4 v: 4.20.0
    with: xfce4-panel tools: xfce4-screensaver avail: xautolock vt: 7
    dm: LightDM v: 1.32.0 Distro: Garuda base: Arch Linux
Machine:
  Type: Laptop System: CLEVO product: W55xEU v: N/A
    serial: <superuser required> Chassis: No Enclosure type: 10
    serial: <superuser required>
  Mobo: CLEVO model: W55xEU v: D02 serial: <superuser required>
    uuid: <superuser required> UEFI: American Megatrends v: 4.6.5
    date: 03/05/2013
Battery:
  ID-1: BAT0 charge: 54.7 Wh (100.0%) condition: 54.7/62.2 Wh (88.0%)
    volts: 12.1 min: 11.1 model: NOTEBOOK BAT type: Li-ion serial: <filter>
    status: full
CPU:
  Info: model: Intel Core i7-3632QM bits: 64 type: MT MCP arch: Ivy Bridge
    gen: core 3 level: v2 built: 2012-15 process: Intel 22nm family: 6
    model-id: 0x3A (58) stepping: 9 microcode: 0x21
  Topology: cpus: 1x dies: 1 clusters: 4 cores: 4 threads: 8 tpc: 2
    smt: enabled cache: L1: 256 KiB desc: d-4x32 KiB; i-4x32 KiB L2: 1024 KiB
    desc: 4x256 KiB L3: 6 MiB desc: 1x6 MiB
  Speed (MHz): avg: 1200 min/max: 1200/3200 scaling: driver: intel_cpufreq
    governor: schedutil cores: 1: 1200 2: 1200 3: 1200 4: 1200 5: 1200 6: 1200
    7: 1200 8: 1200 bogomips: 35119
  Flags: avx ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities: <filter>
Graphics:
  Device-1: Intel 3rd Gen Core processor Graphics vendor: CLEVO/KAPOK
    driver: i915 v: kernel arch: Gen-7 process: Intel 22nm built: 2012-13 ports:
    active: LVDS-1 empty: DP-1,HDMI-A-1,VGA-1 bus-ID: 00:02.0
    chip-ID: 8086:0166 class-ID: 0300
  Display: x11 server: X.Org v: 21.1.16 compositor: xfwm4 v: 4.20.0 driver:
    X: loaded: modesetting alternate: fbdev,intel,vesa dri: crocus gpu: i915
    display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 509x286mm (20.04x11.26")
    s-diag: 584mm (22.99")
  Monitor-1: LVDS-1 model: LG Display 0x037e built: 2011 res:
    mode: 1920x1080 hz: 60 scale: 100% (1) dpi: 141 gamma: 1.2
    size: 345x194mm (13.58x7.64") diag: 396mm (15.6") ratio: 16:9
    modes: 1920x1080
  API: Vulkan v: 1.4.304 layers: 7 device: 0 type: integrated-gpu name: Intel
    HD Graphics 4000 (IVB GT2) driver: N/A device-ID: 8086:0166
    surfaces: xcb,xlib device: 1 type: cpu name: llvmpipe (LLVM 19.1.7 256
    bits) driver: N/A device-ID: 10005:0000 surfaces: xcb,xlib
  API: OpenGL Message: Unable to show GL data. glxinfo is missing.
  Info: Tools: api: vulkaninfo de: xfce4-display-settings
    x11: xdpyinfo, xprop, xrandr
Audio:
  Device-1: Intel 7 Series/C216 Family High Definition Audio
    vendor: CLEVO/KAPOK driver: snd_hda_intel v: kernel bus-ID: 00:1b.0
    chip-ID: 8086:1e20 class-ID: 0403
  API: ALSA v: k6.13.7-arch1-1 status: kernel-api tools: N/A
  Server-1: PipeWire v: 1.4.1 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
    4: pw-jack type: plugin tools: pactl,pw-cat,pw-cli,wpctl
Network:
  Device-1: Intel Centrino Wireless-N 2230 driver: iwlwifi v: kernel pcie:
    gen: 1 speed: 2.5 GT/s lanes: 1 bus-ID: 02:00.0 chip-ID: 8086:0887
    class-ID: 0280
  IF: wlp2s0 state: up mac: <filter>
  Device-2: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
    vendor: CLEVO/KAPOK driver: r8169 v: kernel pcie: gen: 1 speed: 2.5 GT/s
    lanes: 1 port: e000 bus-ID: 03:00.2 chip-ID: 10ec:8168 class-ID: 0200
  IF: enp3s0f2 state: down mac: <filter>
  Info: services: NetworkManager, systemd-timesyncd, wpa_supplicant
Bluetooth:
  Device-1: Intel Centrino Bluetooth Wireless Transceiver driver: btusb v: 0.8
    type: USB rev: 2.0 speed: 12 Mb/s lanes: 1 mode: 1.1 bus-ID: 1-4:2
    chip-ID: 8087:07da class-ID: e001
  Report: btmgmt ID: hci0 rfk-id: 0 state: down bt-service: enabled,running
    rfk-block: hardware: no software: yes address: <filter> bt-v: 4.0 lmp-v: 6
    status: discoverable: no pairing: no
Drives:
  Local Storage: total: 3.86 TiB used: 3.13 TiB (81.2%)
  SMART Message: Required tool smartctl not installed. Check --recommends
  ID-1: /dev/sda maj-min: 8:0 vendor: Crucial model: CT4000MX500SSD1
    size: 3.64 TiB block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s
    tech: SSD serial: <filter> fw-rev: 046 temp: 28.0 C
  ID-2: /dev/sdb maj-min: 8:16 vendor: Kingston model: SMS200S3240G
    size: 223.57 GiB block-size: physical: 512 B logical: 512 B speed: 3.0 Gb/s
    tech: SSD serial: <filter> fw-rev: BBF0 temp: 42.0 C scheme: GPT
Partition:
  ID-1: / raw-size: 223.27 GiB size: 223.27 GiB (100.00%)
    used: 26.17 GiB (11.7%) fs: btrfs dev: /dev/dm-0 maj-min: 254:0
    mapped: luks-61270517-44f2-4f88-8fe2-64c24eeb9c41
  ID-2: /boot/efi raw-size: 300 MiB size: 299.4 MiB (99.80%)
    used: 768 KiB (0.3%) fs: vfat dev: /dev/sdb1 maj-min: 8:17
  ID-3: /home raw-size: 223.27 GiB size: 223.27 GiB (100.00%)
    used: 26.17 GiB (11.7%) fs: btrfs dev: /dev/dm-0 maj-min: 254:0
    mapped: luks-61270517-44f2-4f88-8fe2-64c24eeb9c41
  ID-4: /var/log raw-size: 223.27 GiB size: 223.27 GiB (100.00%)
    used: 26.17 GiB (11.7%) fs: btrfs dev: /dev/dm-0 maj-min: 254:0
    mapped: luks-61270517-44f2-4f88-8fe2-64c24eeb9c41
  ID-5: /var/tmp raw-size: 223.27 GiB size: 223.27 GiB (100.00%)
    used: 26.17 GiB (11.7%) fs: btrfs dev: /dev/dm-0 maj-min: 254:0
    mapped: luks-61270517-44f2-4f88-8fe2-64c24eeb9c41
Swap:
  Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default) zswap: no
  ID-1: swap-1 type: zram size: 15.49 GiB used: 0 KiB (0.0%) priority: 100
    comp: zstd avail: lzo-rle,lzo,lz4,lz4hc,deflate,842 max-streams: 8
    dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 66.0 C mobo: N/A
  Fan Speeds (rpm): N/A
Info:
  Memory: total: 16 GiB available: 15.49 GiB used: 3.3 GiB (21.3%)
  Processes: 293 Power: uptime: 2h 1m states: freeze,mem,disk suspend: deep
    avail: s2idle wakeups: 0 hibernate: platform avail: shutdown, reboot,
    suspend, test_resume image: 6.19 GiB services: upowerd,xfce4-power-manager
    Init: systemd v: 257 default: graphical tool: systemctl
  Packages: pm: pacman pkgs: 1397 libs: 421 tools: pacseek,paru Compilers:
    gcc: 14.2.1 Shell: garuda-inxi default: Bash v: 5.2.37
    running-in: xfce4-terminal inxi: 3.3.37
Garuda (2.7.2-1):
  System install date:     2025-03-20
  Last full system update: 2025-03-21 ↻
  Is partially upgraded:   No
  Relevant software:       snapper NetworkManager dracut
  Windows dual boot:       Probably (Run as root to verify)
  Failed units:  

Fstrim is on arch based distros disabled (standard)
There will probably be reasons why it is disabled.
My mind to fstrim → leave it disabled
special if your system work with FDe.

to read

1 Like

Pointing me to a topic at Fedora Discussion by someone who has only posted four times there, and includes no links or references to back up their assertions isn’t the best way to make your argument.

Before posting here, I had read (and linked to above) the Arch Wiki dm-crypt/Specialties - ArchWiki which in a section above says:

The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications.[3][4] Minimal data leakage in the form of freed block information, perhaps sufficient to determine the filesystem in use, may occur on devices with TRIM enabled.

It then goes on to say:

The following cases can be distinguished:

The device is encrypted with default dm-crypt LUKS mode:
    By default the LUKS header is stored at the beginning of the device and using TRIM is useful to protect header modifications. If for example a compromised LUKS password is revoked, without TRIM the old header will in general still be available for reading until overwritten by another operation; if the drive is stolen in the meanwhile, the attackers could in theory find a way to locate the old header and use it to decrypt the content with the compromised password. 

So there are good security reasons why TRIM support is not enabled by default on dm-crypt devices, but also cases where it has security benefits.

But of course, this is the Garuda Linux Forum and as I made clear above, I have installed Garuda Xfce. And in Garuda Linux (or at least the Xfce edition) btrfs-trim is enabled by default on my encrypted system SSD, which is what led me to ask about fstrim on my data SSD.

my post should you “only” saying: be attention if you use fstrim with fde.
Believe me, some times ago, i had a lot of trouble with this.
(I lost 160 h working time reason sdd + trim + fde)
fstrim + fde
The service fstrim executes on all mounted filesystems on devices that support the discard operation. (standard)

with lsblk --discard you see what´s going on (depends on your fstab)
fstrim is for your hardware nvme/sdd/hdd/usb ( equal which filesystem)
(depends on your fstab/grub.cfg/cryptsetup)

Solid state drive - ArchWiki

btrfs-trim is for btrfs filesystem + other filesystem (depends on your config)

open Btrfs Assistent → tab Btrfs maintenance
If you have nothing changed there, then the btrfs timer handle all mountpoints.

or look /usr/share/btrfsmaintenance + /etc/default/btrfsmaintenance


and you should refrain from mocking in your repost if they are technical questions and it´s not going “directly” about Garuda issues.
Sorry, that’s just my opinion

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.