Re: [PATCH 2/2] test: exercise FUSE_NOTIFY_RESEND

[Luis Henriques <luis@igalia.com>]

Hi!

On Fri, Oct 09 2026, Baokun Li wrote:

> Hi Bernd,
>
> On 2026/10/9 16:19, Bernd Schubert wrote:
>> Hi Baokun,
>>
>> On 10/9/26 09:54, Baokun Li wrote:
>>> test_notify_resend drops the first GETATTR of a file and asks the
>>> kernel to resend pending requests via fuse_lowlevel_notify_resend().
>>> The kernel redelivers the request with the FUSE_UNIQUE_RESEND bit set;
>>> the daemon detects it with fuse_req_is_resend(), answers it, and the
>>> client's stat() completes.
>> to be honest, this is one the features that I have no clue about what it
>> exists for. Why would a daemon drop requests? 
>
> The daemon does not drop them on purpose - they are lost because it
> dies with the requests in flight.  This is the failover scenario the
> feature was added for: the old daemon has already read a request from
> /dev/fuse, but panics before replying to it.
>
> Meanwhile the file descriptor of the connection is preserved - by
> another daemon, or simply by the service manager: systemd's file
> descriptor store keeps the /dev/fuse fd across a daemon restart
> (FDSTORE=1, retrieved again with sd_listen_fds()).
>
> A newly started daemon then takes the fd over and keeps serving
> new requests; the requests the old daemon had already read can be
> recovered with FUSE_NOTIFY_RESEND (760eac73f9f6, "fuse: Introduce a
> new notification type for resend pending requests").
>
>> The use-case I have in my mind is a daemon upgrade, 
>
> Yes, a daemon upgrade is indeed one of the scenarios.  It is the same
> flow as the failover case above, only planned: the old daemon hands
> the fd over to the new daemon instead of dying with it.
>
>> but that would mean that either kernel needs
>> to send a re-lookup of all inodes or that daemon needs to store lookup
>> objects (I personally see these as counter part of kernel inodes). Now,
>> besides not being implemented at all, kernel will have a hard time to
>> send re-lookup requests, unless fuse-server supports lookup by 64 bit
>> node-id.
>
> You're right that the new daemon can only answer the resent
> requests if it can still map their node IDs (and other state) to
> its own objects - that is the "daemon stores lookup objects" side
> you mention, and it is deliberately left to the daemon.
>
> FUSE_NOTIFY_RESEND does not attempt to solve state preservation -
> it only guarantees delivery of the requests that would otherwise
> be unreachable forever, no matter how much state the daemon kept.
>
>> I.e. in my personal opinion the prerequisite of FUSE_NOTIFY_RESEND is
>> missing (which could be LOOKUP_HANDLE and then using that to re-lookup
>> inodes after a daemon termination).
>
> Something like LOOKUP_HANDLE, where the kernel and the daemon pass
> file handles directly so no node ID mapping is needed, would be
> ideal.  However, I think a persistent node ID mapping on the daemon
> side would also work.
>
>> The example below also just does a simple exercise of
>> FUSE_NOTIFY_RESEND, without revealing what it would be useful for - that
>> is the part I would like to see fulfilled by an example.
>>
>
> Yes, it only checks that the API works.  It has no fd preservation
> mechanism and no persistent node ID mapping either.
>
> A full takeover setup needs the fd and state handover, which is daemon
> specific and not something a libfuse test can realistically contain,
> so I think explaining the model in the test and the commit message is
> the right scope.  Let me know if you would prefer something different.

Thank you, Baokun, for the above description (and Bernd for explicitly
CC'ing me to a patchset that I could have missed!).

I had a PR [1] created long time ago that included something similar to
your first patch in this set.  The difference was that I also tried to
solve yet another problem: setting the fd back into libfuse-specific data
structures (i.e. re-initialise libfuse itself).

This was an RFC, which later made me start looking into the LOOKUP_HANDLE.
Which is currently stale, but hopefully to resume soon.

[1] https://github.com/libfuse/libfuse/pull/1219

Cheers,
-- 
Luís