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?
sorry, I have it in our ticket system, but I'm totally occupied with
others issues for weeks *sigh*
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
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).
Thanks
Bernd
