[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpeguXBpyr_3FV1u-VRA9ZSqmGKVWFWZsXPqB-Tqa_JAx=uw@mail.gmail.com>
Date: Wed, 7 Jun 2023 11:29:36 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: Bernd Schubert <bernd.schubert@...tmail.fm>
Cc: Askar Safin <safinaskar@...il.com>,
Luis Chamberlain <mcgrof@...nel.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org,
fuse-devel <fuse-devel@...ts.sourceforge.net>
Subject: Re: [PATCH 0/6] vfs: provide automatic kernel freeze / resume
On Wed, 7 Jun 2023 at 10:13, Bernd Schubert <bernd.schubert@...tmail.fm> wrote:
> Assuming a fuse server process is not handing over requests to other
> threads/forked-processes, isn't the main issue that all fuse server
> tasks are frozen and none is left to take requests? A single non-frozen
> thread should be sufficient for that?
This *might* work. But there could be auxiliary threads, or the
initial thread could be killed, etc. It would not be reliable.
> Ah, when all non flagged processes are frozen first no IO should come
> in. Yeah, it mostly works, but I wonder if init/systemd is not going to
> set that flag as well. And then you have an issue when fuse is on a file
> system used by systemd. My long time ago initial interest on fuse is to
> use fuse as root file system and I still do that for some cases - not
> sure if a flag would be sufficient here. I think a freezing score would
> solve more issues.
> Although probably better to do step by step - flag first and score can
> be added later.
I'm not sure how systemd interacts with the freezing process. If it
does, then the only sane thing to do is to make sure it doesn't have
any filesystem interaction during that time.
Hibernation is a different matter, because it needs the filesystem to
be in a working state while all userspace is frozen. Hibernate to
fuse would bring up a lot of interesting design questions.
Thanks,
Miklos
Powered by blists - more mailing lists