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:   Thu, 04 Aug 2022 01:01:50 +0000
Message-ID: <bug-216322-13602-DlPqmAtHxt@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 #3 from Theodore Tso (tytso@mit.edu) ---
The other consideration is if there is some other userspace application oth=
er
than util-linux which is using the FITRIM ioctl --- for example, what if
systemd decided it needed to reimplement fstrim the way it's reimplemented
syslogd, ntpd, etc., etc., etc.?     In which case, if we change FITRIM so =
that
if it gets a signal or if the system tries to suspend itself, it will return
EAGAIN and fstrim_range.len will have the number of bytes trimmed so far ---
this might cause the systemd-reimplementation (or any other hypothetical us=
ers
of FITRIM) to break if there is a suspend-to-ram happening at an inopportune
time.

So which is worse?=20=20=20

1)   Leaving suspend-to-ram broken if the user is unlucky enough to try to
suspend their laptop while fstrim is run automatically by systemd or out of
crontab?=20=20=20

2)   Breaking random userspace programs that use FITRIM so they doesn't
complete the requested file system/SSD maintenance if the user tries to sus=
pend
their laptop while that program happens to be running?   (We can fix the
userspace programs which use FITRIM so they handle the EAGAIN error return =
as
we find them, of course.   At the moment, it's only util-linux as far as I
know.)

In the long term, #2 seems like the best approach, IMHO.  OTOH, it could be
argued that we've lived with this for years and years and years, and no one=
 has
noticed up until now.

--=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.=