Last night I tried to suspend my computer only to find that, while the screen did go blank for a moment, the computer did not suspend and I only got kicked out to the login screen. After investigating, I found that the suspend was blocked by the fstrim.service that was running at the time. The status of the service looks like this:
april 24 00:58:57 <snip>.home systemd[1]: Starting fstrim.service - Discard unused blocks on filesystems from /etc/fstab...
april 24 01:31:31 <snip>.home fstrim[72861]: /boot/efi: 581,4 MiB (609693696 bytes) trimmed on /dev/nvme0n1p1
april 24 01:31:31 <snip>.home fstrim[72861]: /boot: 564,2 MiB (591622144 bytes) trimmed on /dev/nvme0n1p2
april 24 01:31:31 <snip>.home fstrim[72861]: /: 616,4 GiB (661803417600 bytes) trimmed on /dev/mapper/luks-4a118850-0a13-40af-b844-daec162fc44c
april 24 01:31:31 <snip>.home systemd[1]: fstrim.service: Deactivated successfully.
april 24 01:31:31 <snip>.home systemd[1]: Finished fstrim.service - Discard unused blocks on filesystems from /etc/fstab.
april 24 01:31:31 <snip>.home systemd[1]: fstrim.service: Consumed 17.246s CPU time.
Is fstrim expected to take this long to run? Could it be made to stop and be restarted in the event of an attempt to suspend the computer?
Following breadcrumbs from that thread I found a Bugzilla comment that suggests the slowness is not expected and will be fixed later. That’s good news.
I’m left wondering about the second part of my question though. I don’t know what sorts of trim times can be expected once those patches land in my kernel, but in any case let’s say that my request to suspend the computer happens to come at the same time as a trim operation is happening. Would it be technically possible to “suspend” or cancel the trim and then pick it back up again after the computer wakes up? I realize the facilities for doing this probably don’t really exist right now, but speaking hypothetically, could it be possible, or is trim the sort of operation that has to run to completion in one go once it starts?