Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   bugzilla-daemon@kernel.org
To:     linux-ext4@vger.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
Date:   Tue, 09 Aug 2022 17:48:13 +0000
Message-ID: <bug-216322-13602-tTepK30xfV@https.bugzilla.kernel.org/>
In-Reply-To: <bug-216322-13602@https.bugzilla.kernel.org/>
References: <bug-216322-13602@https.bugzilla.kernel.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Auto-Submitted: auto-generated
MIME-Version: 1.0
Precedence: bulk

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

--- Comment #7 from Theodore Tso (tytso@mit.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 ke=
rnel
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 complet=
ed
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, a=
nd a
subsequent FITRIM will skip block groups that still have the flag set.   Th=
en
trigger the fstrim, and immediately try to suspend the laptop.   If your SS=
D is
sufficiently slow, and your file system is sufficiently large and fragmente=
d,
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 t=
he
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, thi=
ngs
are even worse:

% sudo time fstrim /
[sudo] password for tytso:=20
0.00user 34.56system 13:27.21elapsed 4%CPU (0avgtext+0avgdata 2724maxreside=
nt)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.  :-)

--=20
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.=