linux-ext4 - [Bug 216322] Freezing of tasks failed after 60.004 seconds (1 tasks refusing to freeze... task:fstrim ext4_trim_fs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 09 Aug 2022 17:48:13 +0000
From:   bugzilla-daemon@...nel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 216322] Freezing of tasks failed after 60.004 seconds (1 tasks
 refusing to freeze... task:fstrim  ext4_trim_fs - Dell XPS 13 9310

https://bugzilla.kernel.org/show_bug.cgi?id=216322

--- Comment #7 from Theodore Tso (tytso@....edu) ---
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.