On Fri, Feb 14, 2025 at 12:27 PM Bernd Schubert
<bernd.schubert@xxxxxxxxxxx> wrote:
>
> Hi Joanne,
>
> On 2/14/25 21:01, Joanne Koong wrote:
> > On Wed, Aug 21, 2024 at 8:04 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> >>
> >> On Wed, 21 Aug 2024 at 16:44, Bernd Schubert <bernd.schubert@xxxxxxxxxxx> wrote:
> >>
> >>> struct atomic_open
> >>> {
> >>> uint64_t atomic_open_flags;
> >>> struct fuse_open_out open_out;
> >>> uint8_t future_padding1[16];
> >>> struct fuse_entry_out entry_out;
> >>> uint8_t future_padding2[16];
> >>> }
> >>>
> >>>
> >>> What do you think?
> >>
> >> I'm wondering if something like the "compound procedure" in NFSv4
> >> would work for fuse as well?
> >
> > Are compound requests still something that's planned to be added to
> > fuse given that fuse now has support for sending requests over uring,
> > which diminishes the overhead of kernel/userspace context switches for
> > sending multiple requests vs 1 big compound request?
> >
> > The reason I ask is because the mitigation for the stale attributes
> > data corruption for servers backed by network filesystems we saw in
> > [1] is dependent on this patch / compound requests. If compound
> > requests are no longer useful / planned, then what are your thoughts
> > on [1] as an acceptable solution?
>
Hi Bernd,
> sorry, I have it in our ticket system, but I'm totally occupied with
> others issues for weeks *sigh*
>
No worries!
> Does io-uring really help if there is just on application doing IO to
> the current core/ring-queue?
>
> open - blocking fg request
> getattr - blocking fg request
>
My understanding (and please correct me here if i'm wrong) is that the
main benefit of compound requests is that it bundles multiple requests
into 1 request to minimize kernel/userspace context switches. For fuse
io-uring [2], "motivation ... is... to increase fuse performance by:
Reducing kernel/userspace context switches. Part of that is given by
the ring ring - handling multiple requests on either side of
kernel/userspace without the need to switch per request".
Am I missing something in my understanding of io-uring reducing
context switches?
> If we could dispatch both as bg request and wait for the response it
> might work out, but in the current form not ideal.
>
> I can only try to find the time over the weekend to work on the
> compound reuqest, although need to send out the other patch and
> especially to test it (the one about possible list corruption).
If you need an extra pair of hands, i'm happy to help out with this.
Internally, we'd like to get the proper fix in for the issue in [1],
but we have a hacky workaround for it right now (returning -ESTALE to
redo the lookup and update the file size), so we're not in a huge
rush.
Thanks,
Joanne
[2] https://lore.kernel.org/linux-fsdevel/20250120-fuse-uring-for-6-10-rfc4-v10-0-ca7c5d1007c0@xxxxxxx/
>
>
> Thanks
> Bernd
>
>
>
>
>
