Re: [PATCH v7 0/4] fuse: compound commands

[Amir Goldstein]

On Thu, Jun 4, 2026 at 11:51 AM Horst Birthelmer <horst@xxxxxxxxxxxxxx> 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.