https://bugzilla.kernel.org/show_bug.cgi?id=216322 --- Comment #7 from Theodore Tso (tytso@xxxxxxx) --- I suspect you got lucky. Depending on the SSD's performance in processing discard requests, the size of the file system, and how fragmented the free space might be, it could take several minutes for the FITRIM as executed by fstrim(8) to complete. At the moment, it can be interrupted via a kill -9, but not anything else. It wasn't a matter of the FITRIM failing to make progress; it was making progress, and it was busy sending tons of discard requests to the storage device. It was just that it currently ignores "fake signal" sent by the kernel when it attempts to suspend userspace processes until it completes its task. So if the FITRIM normally takes 3 minutes on that particular storage device, and it suspend was triggered 90 seconds after fstrim(8) was triggered by cron/systemd, the 60 second timeout would have caused the suspend to fail, and then the next suspend would have worked since the FITRIM would have completed before the 60 second timeout expired. To reproduce this failure, presumably what you would want to do is to mount and unmount the file system, since FITRIM sets a flag on a block group after it has been trimmed, which is cleared when blocks are freed in that block group, and a subsequent FITRIM will skip block groups that still have the flag set. Then trigger the fstrim, and immediately try to suspend the laptop. If your SSD is sufficiently slow, and your file system is sufficiently large and fragmented, then you should see it fail. If not, you could try changing the kernel timeout to a smaller value, to a value smaller than the time it takes for the command "time fstrim <mntpnt>": For example, on my new laptop (a 2021 Samsung Galaxy Pro 360): % sudo time fstrim / 0.00user 1.32system 1:14.57elapsed 1%CPU (0avgtext+0avgdata 2732maxresident)k 176inputs+0outputs (0major+137minor)pagefaults 0swaps % df -h / Filesystem Size Used Avail Use% Mounted on /dev/nvme0n1p7 1.1T 28G 996G 3% / This is a 2TB, so if root file system used the full 2TB of space, it would have taken roughly 2 minutes for fstrim to run, and FITRIM is uninterruptible (except via a kill -9 signal). On my Dell Precision Tower development machine, which has an older SSD, things are even worse: % sudo time fstrim / [sudo] password for tytso: 0.00user 34.56system 13:27.21elapsed 4%CPU (0avgtext+0avgdata 2724maxresident)k 10184inputs+0outputs (2major+131minor)pagefaults 0swaps % df -h / Filesystem Size Used Avail Use% Mounted on /dev/mapper/cwcc--vg-root 824G 283G 499G 37% / Please note, I'm not requesting that the kernel timeout be extended from 60 seconds to 15 minutes. We need to find some different solution. :-) -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
