[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <tm57gt2zkazpyjg3qkcxab7h7df2kyayirjbhbqqw3eknwq37h@vpti4li6xufe>
Date: Mon, 21 Jul 2025 14:09:42 +0200
From: Jan Kara <jack@...e.cz>
To: Askar Safin <safinaskar@...omail.com>
Cc: brauner@...nel.org, James.Bottomley@...senpartnership.com,
ardb@...nel.org, boqun.feng@...il.com, david@...morbit.com, djwong@...nel.org,
hch@...radead.org, jack@...e.cz, linux-efi@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, mcgrof@...nel.org,
mingo@...hat.com, pavel@...nel.org, peterz@...radead.org, rafael@...nel.org,
will@...nel.org
Subject: Re: [PATCH v2 0/4] power: wire-up filesystem freeze/thaw with
suspend/resume
Hi!
On Sun 20-07-25 22:23:36, Askar Safin wrote:
> I did experiments on my laptop, and these experiments show that this
> patchset does not solve various longstanding problems related to suspend
> and filesystems. (Even if I enable /sys/power/freeze_filesystems )
>
> Now let me describe problems I had in the past (and still have!) and then
> experiments I did and their results.
>
> So, I had these 3 problems:
>
> - Suspend doesn't work if fstrim in progress (note that I use btrfs as
> root file system)
Right, this is expected because the FITRIM ioctl (syscall as any other)
likely takes too long and so the suspend code looses its patience. There's
nothing VFS can do about this. You can talk to btrfs developers to
periodically check for pending signal / freezing event like e.g. ext4 does
in ext4_trim_interrupted() to avoid suspend failures when FITRIM is
running.
> - Suspend doesn't work if scrub in progress
Similar situation as with FITRIM. This is fully in control of the
filesystem and unless the filesystem adds checks and early abort paths, VFS
cannot do anything.
> - Suspend doesn't work if we try to read from fuse-sshfs filesystem while
> network is down
On the surface the problem is the same as the above two but the details
here are subtly different. Here I expect (although I'm not 100% sure) the
blocked process is inside the FUSE filesystem waiting for the FUSE daemon
to reply (a /proc/<pid>/stack of the blocked process would be useful here).
In theory, FUSE filesystem should be able to make the wait for reply in
TASK_FREEZABLE state which would fix your issue. In any case this is very
likely work for FUSE developers.
So I'm sorry but the patch set you speak about isn't supposed to fix any of
the above issues you hit.
Honza
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists