Re: [PATCH v3] fuse: optional FORGET delivery over io_uring

[Joanne Koong]

On Tue, Apr 28, 2026 at 10:06 AM Li Wang <liwang@xxxxxxxxxx> wrote:
>
> Hi Joanne,
>
> On 27/04/2026 19:31, Joanne Koong wrote:
> > On Mon, Apr 27, 2026 at 10:56 AM Li Wang <liwang@xxxxxxxxxx> wrote:
> >>
> >> Hi Bernd and Joanne,
> >>
> >> On 26/04/2026 23:48, Bernd Schubert wrote:
> >>>
> >> Furthermore, in the current implementation, forget and I/O requests are
> >> dispatched through different paths and handled by different sets of threads.
> >> This means we cannot guarantee their original priority order upon reception,
> >
> > I don't think ordering matters. forgets are inherently asynchronous
> > and there's no correctness dependency on a forget arriving before or
> > after a read/write request. In the /dev/fuse path ordering isn't
> > preserved either (eg the order they're queued by the kernel is not the
> > order they're delivered to userspace).
> >
>
> Yeah, I agree, and I apologize for the confusion. By 'original',
> I meant the logic used before the io_uring path was introduced — where the
> system prioritized reading FORGET requests into the userspace buffer
> while still maintaining fairness. I wasn't referring to the order in which
> the system receives those requests.

Gotcha, thanks for clarifying.

>
> That said, I’m curious: since FORGET is asynchronous and doesn't require
> a reply, it doesn't seem particularly urgent. Why prioritize it? To prevent
> a large memory footprint for metadata-heavy workloads? Could we be more

As I understand it, yes, forgets are the only way the server has of
knowing it is safe to release resources / clean up state. Luis is
working on lookup handles [1] which will help mitigate how much state
the server needs to keep track of, but without that the server needs
to keep locally stashed info for that inode alive so if future
requests for that nodeid come in, it can serve them.

[1] https://lore.kernel.org/linux-fsdevel/20260225112439.27276-1-luis@xxxxxxxxxx/

> aggressive with delays and only send them in batches once a certain
> threshold is met? Also, if a FORGET request is lost for whatever reason,

I think we could but the current approach seems like a reasonable
balance already. i'm not sure I see the benefit, as it seems like the
right threshold would be different for different workloads. imo this
would add complexity for unclear benefit, but I think it'd be ideal to
keep things as simple as possible.

> what are the consequences? Is it just a matter of causing a memory leak?

If a forget request is lost, the server has to keep maintaining local
state for that inode. on server teardown everything gets cleaned up
normally but while the server is alive it's effectively a memory leak.

Thanks,
Joanne

>
> Thanks,
> Li
>