Hi,

I'm not running the latest rolling release available but I haven't found any recent fixed issue concerning this report so today's image is likely affected.

VyOS runs periodically fstrim.timer which in turn executes fstrim.service. I believe this is just inherited from Debian as-is and shipped unmodified. The systemd unit runs:

ExecStart=/sbin/fstrim --listed-in /etc/fstab:/proc/self/mountinfo --verbose --quiet-unsupported

Which feeds information about the filesystems to trim via --listed-in.

This is an except from fstrim(8):

-I, --listed-in list
     Specifies a colon-separated list of files in fstab or kernel mountinfo
     format.  All  missing or empty files are silently ignored. The evalua‐
     tion of the list stops after first non-empty file.

Hence, in VyOS's case, /etc/fstab is only considered (and /proc/self/mountinfo unfortunately ignored) as the first element (/etc/fstab) is non-empty.

vyos@vyos01:~$ cat /etc/fstab 
# UNCONFIGURED FSTAB FOR BASE SYSTEM
overlay / overlay rw 0 0
tmpfs /tmp tmpfs nosuid,nodev 0 0
tmpfs /var/tmp tmpfs nosuid,nodev 0 0

This issue here is that fstrim will ignore /as it's an overlay FS and no further action will be taken. However, what we'd actually want to trim is the actual filesystem behind: /usr/lib/live/mount/persistence

In fact, when running fstrim manually passing only /proc/self/mountinfo then the desired trim actually happens, see:

# Executing the trim as the systemd unit would do:
vyos@vyos01:~$ sudo fstrim --listed-in /etc/fstab:/proc/self/mountinfo --verbose
# Nothing happens!!
# Executing passing only /proc/self/mountinfo, where the actual (and target for trimming) FS is listed
vyos@vyos01:~$ sudo fstrim --listed-in /proc/self/mountinfo --verbose
/usr/lib/live/mount/persistence: 15.7 GiB (16808431616 bytes) trimmed on /dev/sda3
# Voila!

To fix this issue I'd suggest to for instance patch the systemd unit to only consume information from /usr/lib/live/mount/persistence