This series adds a single new opcode, FUSE_COMPOUND, that bundles a
sequence of subrequests into one round trip.  The wire format is

    fuse_in_header (opcode FUSE_COMPOUND)
    fuse_compound_in
      fuse_compound_req_in
      fuse_in_header
      payload
      ... (repeated per subop)

Compound is opt-in per connection and discovered by trial: the kernel
assumes support and clears its flag on the first -ENOSYS reply.
-EOPNOTSUPP declines a specific combination without disabling the
feature.  In both cases the kernel replays the subops individually
via fuse_simple_request(), so callers never need a separate
non-compound code path.

The series ships two consumers:

  - open + getattr, used when fuse_file_open() needs both ff->fh and
    fresh attrs (O_APPEND, or cached attrs already stale).  This
    closes the open-then-stat race described in [1].
  - dentry revalidate, fusing LOOKUP + GETATTR when both the entry
    and the attribute caches are stale.

The matching libfuse pull request is here [2].  It contains a helper
that decodes a compound and runs each subop in turn, plus a
passthrough_hp patch demonstrating both that path and the
alternative of handling the compound entirely server-side.

Compounds were reccently discussed more of a thing for fusex 
but I think we should add them to the 'classic' FUSE as well, 
and as long as fusex hasn't landed and the full fuse channels 
are not here, we could add these here.

[1] https://lore.kernel.org/all/20240813212149.1909627-1-joannelkoong@gmail.com/
[2] https://github.com/libfuse/libfuse/pull/1418

Signed-off-by: Horst Birthelmer <hbirthelmer@ddn.com>
---
Changes in v7:
- simplify fuse_open_args_fill() handling
- share result handling between the open+getattr compound and the old code
- send open+getattr only when the attributes we have are expired
or we have open flag O_APPEND
- remove fuse_compound_alloc()/fuse_compound_free()
- add small header for every request in a compound to send compound flags
to fuse server
- Link to v6: https://lore.kernel.org/r/20260226-fuse-compounds-upstream-v6-0-8585c5fcd2fc@ddn.com

Changes in v6:
- got rid of the count in the compound header
- added the automatic calling of the combined request if the fuse
server doesn't process the compound and the implementation allows it
- due to the variable max operations in the compounds request struct
fuse_compound_free() had be brought back
- Link to v5: https://lore.kernel.org/r/20260210-fuse-compounds-upstream-v5-0-ea0585f62daa@ddn.com

Changes in v5:
- introduced the flag FUSE_COMPOUND_SEPARABLE as discussed here
- simplify result parsing and streamline the code
- simplify the result and error handling for open+getattr
- fixed a couple of issues pointed out by Joanne
- Link to v4: https://lore.kernel.org/r/20260109-fuse-compounds-upstream-v4-0-0d3b82a4666f@ddn.com

Changes in v4:
- removed RFC
- removed the unnecessary 'parsed' variable in fuse_compound_req, since
  we parse the result only once
- reordered the patches about the helper functions to fill in the fuse
  args for open and getattr calls
- Link to v3: https://lore.kernel.org/r/20260108-fuse-compounds-upstream-v3-0-8dc91ebf3740@ddn.com

Changes in v3:
- simplified the data handling for compound commands
- remove the validating functionality, since it was only a helper for
  development
- remove fuse_compound_request() and use fuse_simple_request()
- add helper functions for creating args for open and attr
- use the newly createn helper functions for arg creation for open and
  getattr
- Link to v2: https://lore.kernel.org/r/20251223-fuse-compounds-upstream-v2-0-0f7b4451c85e@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 (4):
      fuse: add compound command to combine multiple requests
      fuse: create helper functions for filling in fuse args for open and getattr
      fuse: add an implementation of open+getattr
      fuse: add compound command for dentry revalidation

 fs/fuse/Makefile          |   2 +-
 fs/fuse/compound.c        | 126 ++++++++++++++++++++++++++++
 fs/fuse/dev.c             | 206 +++++++++++++++++++++++++++++++++++++++++++---
 fs/fuse/dev_uring.c       |  31 ++++++-
 fs/fuse/dir.c             | 139 ++++++++++++++++++++++++++++---
 fs/fuse/file.c            | 115 +++++++++++++++++++++-----
 fs/fuse/fuse_dev_i.h      |   5 ++
 fs/fuse/fuse_i.h          |  39 +++++++++
 fs/fuse/inode.c           |   9 ++
 fs/fuse/ioctl.c           |   2 +-
 include/uapi/linux/fuse.h |  56 +++++++++++++
 11 files changed, 685 insertions(+), 45 deletions(-)
---
base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
change-id: 20251223-fuse-compounds-upstream-c85b4e39b3d3

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

On Thu, Jun 4, 2026 at 11:51 AM Horst Birthelmer <horst@birthelmer.com> wrote:
>
> This series adds a single new opcode, FUSE_COMPOUND, that bundles a
> sequence of subrequests into one round trip.  The wire format is
>
>     fuse_in_header (opcode FUSE_COMPOUND)
>     fuse_compound_in
>       fuse_compound_req_in
>       fuse_in_header
>       payload
>       ... (repeated per subop)
>
> Compound is opt-in per connection and discovered by trial: the kernel
> assumes support and clears its flag on the first -ENOSYS reply.
> -EOPNOTSUPP declines a specific combination without disabling the
> feature.  In both cases the kernel replays the subops individually
> via fuse_simple_request(), so callers never need a separate
> non-compound code path.
>
> The series ships two consumers:
>
>   - open + getattr, used when fuse_file_open() needs both ff->fh and
>     fresh attrs (O_APPEND, or cached attrs already stale).  This
>     closes the open-then-stat race described in [1].
>   - dentry revalidate, fusing LOOKUP + GETATTR when both the entry
>     and the attribute caches are stale.

I am not sure if the intention for fusex is to carry over or phase out GETATTR
in favor of STATX, but apart of the strategic question whether FUSE_COMPOUND
should or should not be added to current FUSE protocol, we need to answer the
more concrete question:

Is FUSE_COMPOUND intended to improve existing unmodified servers
which link with newer libfuse and run on a newer kernel?

If not, then maybe we should start with OPEN/LOOKUP + STATX
from the start.

Thanks,
Amir.

On Fri, Jun 05, 2026 at 10:12:59AM +0200, Amir Goldstein wrote:
> On Thu, Jun 4, 2026 at 11:51 AM Horst Birthelmer <horst@birthelmer.com> wrote:
> >
> > This series adds a single new opcode, FUSE_COMPOUND, that bundles a
> > sequence of subrequests into one round trip.  The wire format is
> >
> >     fuse_in_header (opcode FUSE_COMPOUND)
> >     fuse_compound_in
> >       fuse_compound_req_in
> >       fuse_in_header
> >       payload
> >       ... (repeated per subop)
> >
> > Compound is opt-in per connection and discovered by trial: the kernel
> > assumes support and clears its flag on the first -ENOSYS reply.
> > -EOPNOTSUPP declines a specific combination without disabling the
> > feature.  In both cases the kernel replays the subops individually
> > via fuse_simple_request(), so callers never need a separate
> > non-compound code path.
> >
> > The series ships two consumers:
> >
> >   - open + getattr, used when fuse_file_open() needs both ff->fh and
> >     fresh attrs (O_APPEND, or cached attrs already stale).  This
> >     closes the open-then-stat race described in [1].
> >   - dentry revalidate, fusing LOOKUP + GETATTR when both the entry
> >     and the attribute caches are stale.
> 
> I am not sure if the intention for fusex is to carry over or phase out GETATTR
> in favor of STATX, but apart of the strategic question whether FUSE_COMPOUND
> should or should not be added to current FUSE protocol, we need to answer the
> more concrete question:
> 
> Is FUSE_COMPOUND intended to improve existing unmodified servers
> which link with newer libfuse and run on a newer kernel?
> 
> If not, then maybe we should start with OPEN/LOOKUP + STATX
> from the start.

To your first question about phase out of GETATTR, I don't think so,
since fusex will use the same opcodes, so it will be there and we will
have to fall back IMHO.

I have told this to a couple of people I have talked to about fusex
I would actually favor to negotiate supported opcodes and features in fusex
and adjust and overwrite the write operations accordingly. This of course is
miles away from the current state.

I don't think compounds will do anything for fuse servers that do not support it
and that don't have special cases that could be made faster when basically knowing
on a semantical level what the kernel actually wants (this is like some sort of
lookahead in fuse requests. If you are in fuse_atomic_open() the LOOKUP you are
sending is most likely followed by the CREATE right down below ... but the fuse
server cannot know that unless the kernel tells it)

It could have been when the compound handling of not supported operations would
have been in libfuse (which theoretically it still is), then you will save
user/kernel space switches, but when the kernel has to step in to do the 'legacy'
calls you actually will lose that intial try, where the fuse server tells you
ENOSYS or EOPNOTSUP.

So when linked with a not yet existing new libfuse, we could get faster due to the
lesser switches to user space. Do you think that answers your initial question?

I actually have an implementation of the atomic open (this is counter productive
for upstream, but I'm using it here as a concrete example to calrify the more general
point) and since our fuse server can do the atomic open  way more efficiently 
(everybody knows by now that distributed locks cost you performance) 
I get 15%-20% more performance on metadataa tests.

The definitve answer here is probably somewhere around 'your milage may vary'.
I'm really interested in further discussion about this ... and your opinion here.
Would you want to use compounds for some case?

BTW, OPEN+GETATTR is a special case of OPEN+STATX, isn't it?

> 
> Thanks,
> Amir.

Thanks,
Horst

On 6/5/26 10:49, Horst Birthelmer wrote:
> On Fri, Jun 05, 2026 at 10:12:59AM +0200, Amir Goldstein wrote:
>> On Thu, Jun 4, 2026 at 11:51 AM Horst Birthelmer <horst@birthelmer.com> wrote:
>>>
>>> This series adds a single new opcode, FUSE_COMPOUND, that bundles a
>>> sequence of subrequests into one round trip.  The wire format is
>>>
>>>     fuse_in_header (opcode FUSE_COMPOUND)
>>>     fuse_compound_in
>>>       fuse_compound_req_in
>>>       fuse_in_header
>>>       payload
>>>       ... (repeated per subop)
>>>
>>> Compound is opt-in per connection and discovered by trial: the kernel
>>> assumes support and clears its flag on the first -ENOSYS reply.
>>> -EOPNOTSUPP declines a specific combination without disabling the
>>> feature.  In both cases the kernel replays the subops individually
>>> via fuse_simple_request(), so callers never need a separate
>>> non-compound code path.
>>>
>>> The series ships two consumers:
>>>
>>>   - open + getattr, used when fuse_file_open() needs both ff->fh and
>>>     fresh attrs (O_APPEND, or cached attrs already stale).  This
>>>     closes the open-then-stat race described in [1].
>>>   - dentry revalidate, fusing LOOKUP + GETATTR when both the entry
>>>     and the attribute caches are stale.
>>
>> I am not sure if the intention for fusex is to carry over or phase out GETATTR
>> in favor of STATX, but apart of the strategic question whether FUSE_COMPOUND
>> should or should not be added to current FUSE protocol, we need to answer the
>> more concrete question:
>>
>> Is FUSE_COMPOUND intended to improve existing unmodified servers
>> which link with newer libfuse and run on a newer kernel?
>>
>> If not, then maybe we should start with OPEN/LOOKUP + STATX
>> from the start.
> 
> To your first question about phase out of GETATTR, I don't think so,
> since fusex will use the same opcodes, so it will be there and we will
> have to fall back IMHO.

I agree with Amir and also with recent DDN requirements for DLM - there
is no good reason to keep getattr. Basically for open we need to know
the updated file size. Depending on the backend implementation, getting
additionally the time stamps and other attributes _might_ be expensive.
And that exactly there the statx mask helps.

And I don't think it is related to fusex vs fuse. If libfuse or fuse
server do not support statx with the mask, well, then open+getattr will
just not supported for open+getattr - existing behavior?

> 
> I have told this to a couple of people I have talked to about fusex
> I would actually favor to negotiate supported opcodes and features in fusex
> and adjust and overwrite the write operations accordingly. This of course is
> miles away from the current state.
> 
> I don't think compounds will do anything for fuse servers that do not support it
> and that don't have special cases that could be made faster when basically knowing
> on a semantical level what the kernel actually wants (this is like some sort of
> lookahead in fuse requests. If you are in fuse_atomic_open() the LOOKUP you are
> sending is most likely followed by the CREATE right down below ... but the fuse
> server cannot know that unless the kernel tells it)
> 
> It could have been when the compound handling of not supported operations would
> have been in libfuse (which theoretically it still is), then you will save
> user/kernel space switches, but when the kernel has to step in to do the 'legacy'
> calls you actually will lose that intial try, where the fuse server tells you
> ENOSYS or EOPNOTSUP.
> 
> So when linked with a not yet existing new libfuse, we could get faster due to the
> lesser switches to user space. Do you think that answers your initial question?
> 
> I actually have an implementation of the atomic open (this is counter productive
> for upstream, but I'm using it here as a concrete example to calrify the more general
> point) and since our fuse server can do the atomic open  way more efficiently 
> (everybody knows by now that distributed locks cost you performance) 
> I get 15%-20% more performance on metadataa tests.
> 
> The definitve answer here is probably somewhere around 'your milage may vary'.
> I'm really interested in further discussion about this ... and your opinion here.
> Would you want to use compounds for some case?
> 
> BTW, OPEN+GETATTR is a special case of OPEN+STATX, isn't it?

Exactly, except that statx has a mask built in of what it needs.


Thanks,
Bernd

On Fri, Jun 05, 2026 at 12:49:55PM +0200, Bernd Schubert wrote:
> On 6/5/26 10:49, Horst Birthelmer wrote:
> > On Fri, Jun 05, 2026 at 10:12:59AM +0200, Amir Goldstein wrote:
> >> On Thu, Jun 4, 2026 at 11:51 AM Horst Birthelmer <horst@birthelmer.com> wrote:
> >>>
> >>> This series adds a single new opcode, FUSE_COMPOUND, that bundles a
> >>> sequence of subrequests into one round trip.  The wire format is
> >>>
> >>>     fuse_in_header (opcode FUSE_COMPOUND)
> >>>     fuse_compound_in
> >>>       fuse_compound_req_in
> >>>       fuse_in_header
> >>>       payload
> >>>       ... (repeated per subop)
> >>>
> >>> Compound is opt-in per connection and discovered by trial: the kernel
> >>> assumes support and clears its flag on the first -ENOSYS reply.
> >>> -EOPNOTSUPP declines a specific combination without disabling the
> >>> feature.  In both cases the kernel replays the subops individually
> >>> via fuse_simple_request(), so callers never need a separate
> >>> non-compound code path.
> >>>
> >>> The series ships two consumers:
> >>>
> >>>   - open + getattr, used when fuse_file_open() needs both ff->fh and
> >>>     fresh attrs (O_APPEND, or cached attrs already stale).  This
> >>>     closes the open-then-stat race described in [1].
> >>>   - dentry revalidate, fusing LOOKUP + GETATTR when both the entry
> >>>     and the attribute caches are stale.
> >>
> >> I am not sure if the intention for fusex is to carry over or phase out GETATTR
> >> in favor of STATX, but apart of the strategic question whether FUSE_COMPOUND
> >> should or should not be added to current FUSE protocol, we need to answer the
> >> more concrete question:
> >>
> >> Is FUSE_COMPOUND intended to improve existing unmodified servers
> >> which link with newer libfuse and run on a newer kernel?
> >>
> >> If not, then maybe we should start with OPEN/LOOKUP + STATX
> >> from the start.
> > 
> > To your first question about phase out of GETATTR, I don't think so,
> > since fusex will use the same opcodes, so it will be there and we will
> > have to fall back IMHO.
> 
> I agree with Amir and also with recent DDN requirements for DLM - there
> is no good reason to keep getattr. Basically for open we need to know
> the updated file size. Depending on the backend implementation, getting
> additionally the time stamps and other attributes _might_ be expensive.
> And that exactly there the statx mask helps.
> 
> And I don't think it is related to fusex vs fuse. If libfuse or fuse
> server do not support statx with the mask, well, then open+getattr will
> just not supported for open+getattr - existing behavior?
> 
> > 
> > I have told this to a couple of people I have talked to about fusex
> > I would actually favor to negotiate supported opcodes and features in fusex
> > and adjust and overwrite the write operations accordingly. This of course is
> > miles away from the current state.
> > 
> > I don't think compounds will do anything for fuse servers that do not support it
> > and that don't have special cases that could be made faster when basically knowing
> > on a semantical level what the kernel actually wants (this is like some sort of
> > lookahead in fuse requests. If you are in fuse_atomic_open() the LOOKUP you are
> > sending is most likely followed by the CREATE right down below ... but the fuse
> > server cannot know that unless the kernel tells it)
> > 
> > It could have been when the compound handling of not supported operations would
> > have been in libfuse (which theoretically it still is), then you will save
> > user/kernel space switches, but when the kernel has to step in to do the 'legacy'
> > calls you actually will lose that intial try, where the fuse server tells you
> > ENOSYS or EOPNOTSUP.
> > 
> > So when linked with a not yet existing new libfuse, we could get faster due to the
> > lesser switches to user space. Do you think that answers your initial question?
> > 
> > I actually have an implementation of the atomic open (this is counter productive
> > for upstream, but I'm using it here as a concrete example to calrify the more general
> > point) and since our fuse server can do the atomic open  way more efficiently 
> > (everybody knows by now that distributed locks cost you performance) 
> > I get 15%-20% more performance on metadataa tests.
> > 
> > The definitve answer here is probably somewhere around 'your milage may vary'.
> > I'm really interested in further discussion about this ... and your opinion here.
> > Would you want to use compounds for some case?
> > 
> > BTW, OPEN+GETATTR is a special case of OPEN+STATX, isn't it?
> 
> Exactly, except that statx has a mask built in of what it needs.

In this regard. I think we can probably make it OPEN+STATX and set the appropriate mask.

> Thanks,
> Bernd

On Fri, Jun 5, 2026 at 10:49 AM Horst Birthelmer <horst@birthelmer.de> wrote:
>
> On Fri, Jun 05, 2026 at 10:12:59AM +0200, Amir Goldstein wrote:
> > On Thu, Jun 4, 2026 at 11:51 AM Horst Birthelmer <horst@birthelmer.com> wrote:
> > >
> > > This series adds a single new opcode, FUSE_COMPOUND, that bundles a
> > > sequence of subrequests into one round trip.  The wire format is
> > >
> > >     fuse_in_header (opcode FUSE_COMPOUND)
> > >     fuse_compound_in
> > >       fuse_compound_req_in
> > >       fuse_in_header
> > >       payload
> > >       ... (repeated per subop)
> > >
> > > Compound is opt-in per connection and discovered by trial: the kernel
> > > assumes support and clears its flag on the first -ENOSYS reply.
> > > -EOPNOTSUPP declines a specific combination without disabling the
> > > feature.  In both cases the kernel replays the subops individually
> > > via fuse_simple_request(), so callers never need a separate
> > > non-compound code path.
> > >
> > > The series ships two consumers:
> > >
> > >   - open + getattr, used when fuse_file_open() needs both ff->fh and
> > >     fresh attrs (O_APPEND, or cached attrs already stale).  This
> > >     closes the open-then-stat race described in [1].
> > >   - dentry revalidate, fusing LOOKUP + GETATTR when both the entry
> > >     and the attribute caches are stale.
> >
> > I am not sure if the intention for fusex is to carry over or phase out GETATTR
> > in favor of STATX, but apart of the strategic question whether FUSE_COMPOUND
> > should or should not be added to current FUSE protocol, we need to answer the
> > more concrete question:
> >
> > Is FUSE_COMPOUND intended to improve existing unmodified servers
> > which link with newer libfuse and run on a newer kernel?
> >
> > If not, then maybe we should start with OPEN/LOOKUP + STATX
> > from the start.
>
> To your first question about phase out of GETATTR, I don't think so,
> since fusex will use the same opcodes, so it will be there and we will
> have to fall back IMHO.
>
> I have told this to a couple of people I have talked to about fusex
> I would actually favor to negotiate supported opcodes and features in fusex
> and adjust and overwrite the write operations accordingly. This of course is
> miles away from the current state.
>
> I don't think compounds will do anything for fuse servers that do not support it
> and that don't have special cases that could be made faster when basically knowing
> on a semantical level what the kernel actually wants (this is like some sort of
> lookahead in fuse requests. If you are in fuse_atomic_open() the LOOKUP you are
> sending is most likely followed by the CREATE right down below ... but the fuse
> server cannot know that unless the kernel tells it)
>
> It could have been when the compound handling of not supported operations would
> have been in libfuse (which theoretically it still is), then you will save
> user/kernel space switches, but when the kernel has to step in to do the 'legacy'
> calls you actually will lose that intial try, where the fuse server tells you
> ENOSYS or EOPNOTSUP.
>
> So when linked with a not yet existing new libfuse, we could get faster due to the
> lesser switches to user space. Do you think that answers your initial question?
>
> I actually have an implementation of the atomic open (this is counter productive
> for upstream, but I'm using it here as a concrete example to calrify the more general
> point) and since our fuse server can do the atomic open  way more efficiently
> (everybody knows by now that distributed locks cost you performance)
> I get 15%-20% more performance on metadataa tests.
>
> The definitve answer here is probably somewhere around 'your milage may vary'.
> I'm really interested in further discussion about this ... and your opinion here.
> Would you want to use compounds for some case?

No, I do not have any use cases for compounds that I am aware of.

Compounds of READDIR+STATX was discussed as an technical alternative
to READDIRPLUS2 which would need to return backing_ids, but I am still
if this direction is worth pursuing.

>
> BTW, OPEN+GETATTR is a special case of OPEN+STATX, isn't it?
>

Yes, I was asking whether FUSE_STATX is expected to supersede
FUSE_GETATTR in fusex. I don't know that answer.

Thanks,
Amir.

On Fri, Jun 05, 2026 at 11:15:03AM +0200, Amir Goldstein wrote:
> On Fri, Jun 5, 2026 at 10:49 AM Horst Birthelmer <horst@birthelmer.de> wrote:
> >
> > On Fri, Jun 05, 2026 at 10:12:59AM +0200, Amir Goldstein wrote:
> > > On Thu, Jun 4, 2026 at 11:51 AM Horst Birthelmer <horst@birthelmer.com> wrote:
> > > >
> > > > This series adds a single new opcode, FUSE_COMPOUND, that bundles a
> > > > sequence of subrequests into one round trip.  The wire format is
> > > >
> > > >     fuse_in_header (opcode FUSE_COMPOUND)
> > > >     fuse_compound_in
> > > >       fuse_compound_req_in
> > > >       fuse_in_header
> > > >       payload
> > > >       ... (repeated per subop)
> > > >
> > > > Compound is opt-in per connection and discovered by trial: the kernel
> > > > assumes support and clears its flag on the first -ENOSYS reply.
> > > > -EOPNOTSUPP declines a specific combination without disabling the
> > > > feature.  In both cases the kernel replays the subops individually
> > > > via fuse_simple_request(), so callers never need a separate
> > > > non-compound code path.
> > > >
> > > > The series ships two consumers:
> > > >
> > > >   - open + getattr, used when fuse_file_open() needs both ff->fh and
> > > >     fresh attrs (O_APPEND, or cached attrs already stale).  This
> > > >     closes the open-then-stat race described in [1].
> > > >   - dentry revalidate, fusing LOOKUP + GETATTR when both the entry
> > > >     and the attribute caches are stale.
> > >
> > > I am not sure if the intention for fusex is to carry over or phase out GETATTR
> > > in favor of STATX, but apart of the strategic question whether FUSE_COMPOUND
> > > should or should not be added to current FUSE protocol, we need to answer the
> > > more concrete question:
> > >
> > > Is FUSE_COMPOUND intended to improve existing unmodified servers
> > > which link with newer libfuse and run on a newer kernel?
> > >
> > > If not, then maybe we should start with OPEN/LOOKUP + STATX
> > > from the start.
> >
> > To your first question about phase out of GETATTR, I don't think so,
> > since fusex will use the same opcodes, so it will be there and we will
> > have to fall back IMHO.
> >
> > I have told this to a couple of people I have talked to about fusex
> > I would actually favor to negotiate supported opcodes and features in fusex
> > and adjust and overwrite the write operations accordingly. This of course is
> > miles away from the current state.
> >
> > I don't think compounds will do anything for fuse servers that do not support it
> > and that don't have special cases that could be made faster when basically knowing
> > on a semantical level what the kernel actually wants (this is like some sort of
> > lookahead in fuse requests. If you are in fuse_atomic_open() the LOOKUP you are
> > sending is most likely followed by the CREATE right down below ... but the fuse
> > server cannot know that unless the kernel tells it)
> >
> > It could have been when the compound handling of not supported operations would
> > have been in libfuse (which theoretically it still is), then you will save
> > user/kernel space switches, but when the kernel has to step in to do the 'legacy'
> > calls you actually will lose that intial try, where the fuse server tells you
> > ENOSYS or EOPNOTSUP.
> >
> > So when linked with a not yet existing new libfuse, we could get faster due to the
> > lesser switches to user space. Do you think that answers your initial question?
> >
> > I actually have an implementation of the atomic open (this is counter productive
> > for upstream, but I'm using it here as a concrete example to calrify the more general
> > point) and since our fuse server can do the atomic open  way more efficiently
> > (everybody knows by now that distributed locks cost you performance)
> > I get 15%-20% more performance on metadataa tests.
> >
> > The definitve answer here is probably somewhere around 'your milage may vary'.
> > I'm really interested in further discussion about this ... and your opinion here.
> > Would you want to use compounds for some case?
> 
> No, I do not have any use cases for compounds that I am aware of.
> 
> Compounds of READDIR+STATX was discussed as an technical alternative
> to READDIRPLUS2 which would need to return backing_ids, but I am still
> if this direction is worth pursuing.
> 
> >
> > BTW, OPEN+GETATTR is a special case of OPEN+STATX, isn't it?
> >
> 
> Yes, I was asking whether FUSE_STATX is expected to supersede
> FUSE_GETATTR in fusex. I don't know that answer.

I would support that idea, if it was up to me. 
Fortunately it's not ;-)

> 
> Thanks,
> Amir.

Thanks,
Horst