Critical: fstrim.service is broken on Fedora Silverblue due to ComposeFS (Ignored /sysroot)

Ask Fedora
,
1

Hello everyone,

I recently discovered a serious issue regarding SSD maintenance on Fedora Silverblue (specifically since the integration of ComposeFS).

When inspecting my logs with journalctl -u fstrim.service, I noticed that the weekly automated TRIM process entirely skips the real root partition located at /sysroot. It only trims /home and /boot, but completely ignores the core OS.

This happens because the default fstrim.service executes /usr/bin/fstrim --listed-in /etc/fstab:/proc/self/mountinfo, which completely misses the actual underlying physical block device due to the new virtual nature of the ComposeFS root.

Running a manual sudo fstrim /sysroot --verbose works flawlessly and freed over 140 GB of block garbage on my encrypted LUKS drive that the system has been hoarding for months. Without this manual intervention, users are facing silent SSD degradation, write-performance loss, and micro-stuttering during rpm-ostree layered updates.

I am aware of the open GitHub issue (#689) regarding this topic. However, considering the risk of premature SSD wear and tear for atomic desktop users, I wanted to ask:

  1. Is there an official upstream fix or automated workaround coming to Fedora updates anytime soon to address this?
  2. Are there plans to ship a transient systemd drop-in file or override out of the box until systemd/ostree resolve how they scale inside ComposeFS?

Is there any woraround at the moment that I can try?

Any insights from the Silverblue team on the ETA for a fix would be highly appreciated. Thanks!

3

Workaround is in https://github.com/fedora-silverblue/issue-tracker/issues/689 / https://forge.fedoraproject.org/atomic/tracker/issues/81.

A proper fix would require a discussion with upstream (util-linux) on how to best fix that.

As always, this is an open source project. Changes happen when contributors step up to do the work and open PRs.

4

Just a question. Is this an issue for btrfs filesystems as well? I am asking because here https://wiki.archlinux.org/title/Btrfs#SSD_TRIM I found

```
A Btrfs file system is able to free unused blocks from an SSD drive supporting the TRIM command. Asynchronous discard support is available with mount option discard=async, and is enabled by default as of linux 6.2. Freed extents are not discarded immediately, but grouped together and trimmed later by a separate worker thread, improving commit latency.
```

5

I looked further and ran sudo dmesg | grep -i discard

[    0.000000] Command line: BOOT_IMAGE=(hd0,gpt2)/ostree/default-8ce7e660dd084d2438e19ffab4d7396583b1cc938df3e895c36d6cf4cff04e80/vmlinuz-7.0.12-201.fc44.x86_64 ostree=/ostree/boot.1/default/8ce7e660dd084d2438e19ffab4d7396583b1cc938df3e895c36d6cf4cff04e80/0 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init rd.luks.uuid=luks-0bb53b68-2243-4bdf-9e79-5c1aa942eb47 rhgb quiet root=UUID=d74aafae-ea7f-447e-890b-a9e8ef2b6504 vconsole.keymap=us-colemak rw rootflags=subvol=root,compress=zstd:1 rd.luks.options=discard amdgpu.dcdebugmask=0x410
[    0.045724] Kernel command line: BOOT_IMAGE=(hd0,gpt2)/ostree/default-8ce7e660dd084d2438e19ffab4d7396583b1cc938df3e895c36d6cf4cff04e80/vmlinuz-7.0.12-201.fc44.x86_64 ostree=/ostree/boot.1/default/8ce7e660dd084d2438e19ffab4d7396583b1cc938df3e895c36d6cf4cff04e80/0 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init rd.luks.uuid=luks-0bb53b68-2243-4bdf-9e79-5c1aa942eb47 rhgb quiet root=UUID=d74aafae-ea7f-447e-890b-a9e8ef2b6504 vconsole.keymap=us-colemak rw rootflags=subvol=root,compress=zstd:1 rd.luks.options=discard amdgpu.dcdebugmask=0x410
[   17.275499] BTRFS info (device dm-0): turning on async discard
[   24.692113] BTRFS info (device dm-1): turning on async discard

For the two SSDs in my system async discard is turned on and the kernel command line has rd.luks.options=discard which presumably required for LUKS TRIM passthrough

So, I should be fine.