[v2] fuse: compound commands

[PATCH RFC v2 0/2] fuse: compound commands

Posted by Horst Birthelmer 1 month, 2 weeks ago

In the discussion about open+getattr here [1] Bernd and Miklos talked
about the need for a compound command in fuse that could send multiple
commands to a fuse server.
    
Here's a propsal for exactly that compound command with an example
(the mentioned open+getattr).
    
[1] https://lore.kernel.org/linux-fsdevel/CAJfpegshcrjXJ0USZ8RRdBy=e0MxmBTJSCE0xnxG8LXgXy-xuQ@mail.gmail.com/

Signed-off-by: Horst Birthelmer <hbirthelmer@ddn.com>
---
Changes in v2:
- fixed issues with error handling in the compounds as well as in the
  open+getattr
- Link to v1: https://lore.kernel.org/r/20251223-fuse-compounds-upstream-v1-0-7bade663947b@ddn.com

---
Horst Birthelmer (2):
      fuse: add compound command to combine multiple requests
      fuse: add an implementation of open+getattr

 fs/fuse/Makefile          |   2 +-
 fs/fuse/compound.c        | 368 ++++++++++++++++++++++++++++++++++++++++++++++
 fs/fuse/dev.c             |  25 ++++
 fs/fuse/file.c            | 125 ++++++++++++++--
 fs/fuse/fuse_i.h          |  20 ++-
 fs/fuse/inode.c           |   6 +
 fs/fuse/ioctl.c           |   2 +-
 include/uapi/linux/fuse.h |  37 +++++
 8 files changed, 566 insertions(+), 19 deletions(-)
---
base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
change-id: 20251223-fuse-compounds-upstream-c85b4e39b3d3

Best regards,
-- 
Horst Birthelmer <hbirthelmer@ddn.com>

Re: [PATCH RFC v2 0/2] fuse: compound commands

Posted by Jingbo Xu 1 month, 1 week ago

Hi Horst & Bernd,

On 12/24/25 6:13 AM, Horst Birthelmer wrote:
> In the discussion about open+getattr here [1] Bernd and Miklos talked
> about the need for a compound command in fuse that could send multiple
> commands to a fuse server.
>     
> Here's a propsal for exactly that compound command with an example
> (the mentioned open+getattr).
>     
> [1] https://lore.kernel.org/linux-fsdevel/CAJfpegshcrjXJ0USZ8RRdBy=e0MxmBTJSCE0xnxG8LXgXy-xuQ@mail.gmail.com/
> 

To achieve close-to-open, why not just invalidate the cached attr on
open so that the following access to the attr would trigger a new
FUSE_GETATTR request to fetch the latest attr from server?

-- 
Thanks,
Jingbo

Re: Re: [PATCH RFC v2 0/2] fuse: compound commands

Posted by Horst Birthelmer 1 month, 1 week ago

On Mon, Dec 29, 2025 at 02:03:02PM +0800, Jingbo Xu wrote:
> Hi Horst & Bernd,
> 
> On 12/24/25 6:13 AM, Horst Birthelmer wrote:
> > In the discussion about open+getattr here [1] Bernd and Miklos talked
> > about the need for a compound command in fuse that could send multiple
> > commands to a fuse server.
> >     
> > Here's a propsal for exactly that compound command with an example
> > (the mentioned open+getattr).
> >     
> > [1] https://lore.kernel.org/linux-fsdevel/CAJfpegshcrjXJ0USZ8RRdBy=e0MxmBTJSCE0xnxG8LXgXy-xuQ@mail.gmail.com/
> > 
> 
> To achieve close-to-open, why not just invalidate the cached attr on
> open so that the following access to the attr would trigger a new
> FUSE_GETATTR request to fetch the latest attr from server?
> 

Hi Jingbo,

you are probably right, that it can be achieved that way. I thas some consequences that can be avoided, like having to wait at a later moment for the attributes to be fetched.

The main goal of this patch however was not close-to-open, even though it was discussed in that context.

We can do a lot more with the compounds than just fix close-to-open consistency. As Bernd mentioned, I am very close to havin implemented the fuse_atomic_open() call with compounds, namely the atomic combination of lookup+create.
And there are some more ideas out there.

open+getattr was just the low hanging fruit in this case.

Cheers,
Horst

Re: [PATCH RFC v2 0/2] fuse: compound commands

Posted by Jingbo Xu 1 month, 1 week ago


On 12/30/25 4:36 PM, Horst Birthelmer wrote:
> On Mon, Dec 29, 2025 at 02:03:02PM +0800, Jingbo Xu wrote:
>> Hi Horst & Bernd,
>>
>> On 12/24/25 6:13 AM, Horst Birthelmer wrote:
>>> In the discussion about open+getattr here [1] Bernd and Miklos talked
>>> about the need for a compound command in fuse that could send multiple
>>> commands to a fuse server.
>>>     
>>> Here's a propsal for exactly that compound command with an example
>>> (the mentioned open+getattr).
>>>     
>>> [1] https://lore.kernel.org/linux-fsdevel/CAJfpegshcrjXJ0USZ8RRdBy=e0MxmBTJSCE0xnxG8LXgXy-xuQ@mail.gmail.com/
>>>
>>
>> To achieve close-to-open, why not just invalidate the cached attr on
>> open so that the following access to the attr would trigger a new
>> FUSE_GETATTR request to fetch the latest attr from server?
>>
> 
> Hi Jingbo,
> 
> you are probably right, that it can be achieved that way. I thas some consequences that can be avoided, like having to wait at a later moment for the attributes to be fetched.
> 
> The main goal of this patch however was not close-to-open, even though it was discussed in that context.
> 
> We can do a lot more with the compounds than just fix close-to-open consistency. As Bernd mentioned, I am very close to havin implemented the fuse_atomic_open() call with compounds, namely the atomic combination of lookup+create.
> And there are some more ideas out there.
> 
> open+getattr was just the low hanging fruit in this case.


Got it. Thanks.

-- 
Thanks,
Jingbo

Re: [PATCH RFC v2 0/2] fuse: compound commands

Posted by Bernd Schubert 1 month, 1 week ago

On 12/29/25 07:03, Jingbo Xu wrote:
> Hi Horst & Bernd,
> 
> On 12/24/25 6:13 AM, Horst Birthelmer wrote:
>> In the discussion about open+getattr here [1] Bernd and Miklos talked
>> about the need for a compound command in fuse that could send multiple
>> commands to a fuse server.
>>     
>> Here's a propsal for exactly that compound command with an example
>> (the mentioned open+getattr).
>>     
>> [1] https://lore.kernel.org/linux-fsdevel/CAJfpegshcrjXJ0USZ8RRdBy=e0MxmBTJSCE0xnxG8LXgXy-xuQ@mail.gmail.com/
>>
> 
> To achieve close-to-open, why not just invalidate the cached attr on
> open so that the following access to the attr would trigger a new
> FUSE_GETATTR request to fetch the latest attr from server?
> 
> 

Hi Jingbo,

because that slows down operation. Doing in 1 step is faster.

https://lore.kernel.org/r/20240820211735.2098951-1-bschubert@ddn.com

https://lore.kernel.org/all/20240813212149.1909627-1-joannelkoong@gmail.com/

Initially Joanne had created the 1st patch and I had asked to do that in
one step and created open+getattr v2 with a new op code. Miklos then
objected and asked for a compound version to avoid too many new op
codes. Horst is in the mean time also working on atomic open using
compounds and I have another use case for attribute updates on writes.
I.e. this is the 3rd attempt.

Thanks,
Bernd