[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877bzo5z1u.fsf@igalia.com>
Date: Thu, 31 Jul 2025 13:23:41 +0100
From: Luis Henriques <luis@...lia.com>
To: Christian Brauner <brauner@...nel.org>
Cc: "Darrick J. Wong" <djwong@...nel.org>, Miklos Szeredi
<miklos@...redi.hu>, Bernd Schubert <bschubert@....com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] Another take at restarting FUSE servers
On Thu, Jul 31 2025, Christian Brauner wrote:
> On Wed, Jul 30, 2025 at 03:04:00PM +0100, Luis Henriques wrote:
>> Hi Darrick,
>>
>> On Tue, Jul 29 2025, Darrick J. Wong wrote:
>>
>> > On Tue, Jul 29, 2025 at 02:56:02PM +0100, Luis Henriques wrote:
>> >> Hi!
>> >>
>> >> I know this has been discussed several times in several places, and the
>> >> recent(ish) addition of NOTIFY_RESEND is an important step towards being
>> >> able to restart a user-space FUSE server.
>> >>
>> >> While looking at how to restart a server that uses the libfuse lowlevel
>> >> API, I've created an RFC pull request [1] to understand whether adding
>> >> support for this operation would be something acceptable in the project.
>> >
>> > Just speaking for fuse2fs here -- that would be kinda nifty if libfuse
>> > could restart itself. It's unclear if doing so will actually enable us
>> > to clear the condition that caused the failure in the first place, but I
>> > suppose fuse2fs /does/ have e2fsck -fy at hand. So maybe restarts
>> > aren't totally crazy.
>>
>> Maybe my PR lacks a bit of ambition -- it's goal wasn't to have libfuse do
>> the restart itself. Instead, it simply adds some visibility into the
>> opaque data structures so that a FUSE server could re-initialise a session
>> without having to go through a full remount.
>>
>> But sure, there are other things that could be added to the library as
>> well. For example, in my current experiments, the FUSE server needs start
>> some sort of "file descriptor server" to keep the fd alive for the
>> restart. This daemon could be optionally provided in libfuse itself,
>> which could also be used to store all sorts of blobs needed by the file
>> system after recovery is done.
>
> Fwiw, for most use-cases you really just want to use systemd's file
> descriptor store to persist the /dev/fuse connection:
> https://systemd.io/FILE_DESCRIPTOR_STORE/
Thank you, Christian. I guess I should have mentioned systemd's fdstore
here. In fact, I knew about it, but in my experiments I decided not to
use it because it's trivial to keep the fd alive[1] (and also because my
test environment doesn't run systemd).
But still, any eventual libfuse support could still include the interface
with fdstore for that.
[1] Obviously "it's trivial" for my experiments. Doing it in a secure way
is probably a bit more challenging.
Cheers,
--
Luís
>
>>
>> >> The PR doesn't do anything sophisticated, it simply hacks into the opaque
>> >> libfuse data structures so that a server could set some of the sessions'
>> >> fields.
>> >>
>> >> So, a FUSE server simply has to save the /dev/fuse file descriptor and
>> >> pass it to libfuse while recovering, after a restart or a crash. The
>> >> mentioned NOTIFY_RESEND should be used so that no requests are lost, of
>> >> course. And there are probably other data structures that user-space file
>> >> systems will have to keep track as well, so that everything can be
>> >> restored. (The parameters set in the INIT phase, for example.)
>> >
>> > Yeah, I don't know how that would work in practice. Would the kernel
>> > send back the old connection flags and whatnot via some sort of
>> > FUSE_REINIT request, and the fuse server can either decide that it will
>> > try to recover, or just bail out?
>>
>> That would be an option. But my current idea would be that the server
>> would need to store those somewhere and simply assume they are still OK
>
> The fdstore currently allows to associate a name with a file descriptor
> in the fdstore. That name would allow you to associate the options with
> the fuse connection. However, I would not rule it out that additional
> metadata could be attached to file descriptors in the fdstore if that's
> something that's needed.
Powered by blists - more mailing lists