Yes. fstrim.timer can trim a mounted XFS filesystem. XFS supports discard, and its current manual recommends periodic fstrim rather than continuous discard for most use cases. The timer is only the scheduler, however: every layer between XFS and the SSD or thin-provisioned datastore must pass the discard request.
What the Timer Actually Runs
On systemd-based distributions, fstrim.timer normally activates a periodic fstrim.service, often weekly. The service invokes fstrim across eligible mounted filesystems. Distribution unit files can differ, so inspect the local definition rather than assuming a schedule:
systemctl status fstrim.timer
systemctl list-timers fstrim.timer
systemctl cat fstrim.service
systemctl cat fstrim.timer
Enable the timer when the distribution does not already do so:
sudo systemctl enable --now fstrim.timer
This schedules future work; it does not prove the storage accepts discard.
Test XFS Safely
Use verbose mode against the specific mount point first:
sudo fstrim -v /mountpoint
For a non-destructive capability check, current util-linux provides dry-run behaviour through --dry-run where supported by the installed version. Confirm local syntax with fstrim --help and man fstrim.
The official fstrim manual defines it as discarding blocks not in use by a mounted filesystem, which is useful for SSDs and thin-provisioned storage. fstrim -a processes mounted filesystems on devices that support discard; -A follows eligible entries from /etc/fstab.
A successful command reports a byte range submitted for discard. That number is not necessarily fresh deleted data. The manual warns that repeated calls may report the same amount, depending on the filesystem and storage stack. Use storage allocation and device telemetry to prove reclamation.
Verify Every Storage Layer
Start with the filesystem and mount:
findmnt -no FSTYPE,SOURCE,OPTIONS /mountpoint
xfs_info /mountpoint
Then inspect the block-device topology and discard limits:
lsblk --discard
lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINTS,DISC-GRAN,DISC-MAX
Non-zero discard granularity and maximum values indicate that the kernel sees discard capability on that path. A zero value suggests that a device, RAID layer, encryption mapping, SAN, USB bridge, or virtual controller is not advertising it.
For LVM thin provisioning, device mapper must pass discard to the thin pool. For encrypted mappings, discard may be disabled deliberately because it can reveal allocation patterns. For hardware RAID, support depends on controller firmware, media type, and virtual-disk policy.
Inside a VM, the guest filesystem can issue discard only if the virtual controller and disk expose the feature. The hypervisor and backing datastore must then translate it into space reclamation. A successful guest fstrim does not by itself prove the storage array returned capacity to its free pool.
Periodic TRIM Versus the discard Mount Option
The XFS manual documents both discard and nodiscard, but recommends using fstrim. Continuous discard submits requests as files are freed, adding work to the deletion path. Periodic trimming batches that work at a controlled time.
Do not add the discard mount option merely because the timer exists. Choose one strategy based on the storage vendor’s guidance and performance testing. For most general-purpose servers, the distribution’s periodic timer is the conservative starting point.
Common Results
fstrim: the discard operation is not supported means the mounted path does not expose discard end to end. It does not mean XFS lacks support. Inspect the block stack.
A report of zero bytes can be normal when no newly releasable extents exist, the storage has already been trimmed, or the minimum extent threshold excludes small ranges. A very large repeated number does not prove the SSD is being physically erased each week.
If fstrim.timer is inactive, check whether the distribution uses another service or policy before enabling a duplicate schedule. If the service fails on one mount, inspect its journal:
journalctl -u fstrim.service
Practical Verification Checklist
Confirm the mount is XFS, run fstrim -v on that mount, inspect lsblk --discard, and review each intervening mapping. Enable the timer, then check its next run and service journal. On thin storage, compare allocated capacity before and after deleting test data, syncing, and trimming according to vendor guidance.
XFS is therefore not the limiting question. fstrim.timer works with XFS; the real test is whether discard survives the complete path from filesystem to the physical or virtual storage that can reclaim it.
