Re: [PATCH] fuse: add folio_max_order and folio_min_order controls in fusectl

[Joanne Koong]

On Fri, Jul 3, 2026 at 2:31 AM Vadlakonda Swetha <swethav0411@xxxxxxxxx> wrote:
>
> Expose `folio_max_order` and `folio_min_order` entries under the FUSE
> control filesystem (`/sys/fs/fuse/connections/<connection_id>/`).
>
> Motivation:
> For fuse based systems like GCSFuse (Google Cloud Storage Fuse), large
> folios gives a significant boost to the read performance.
> - Without large folios, single file read perf is capped at 3GiB/s
> - With large folios, we are able to achieve 12GiB/s, 1MB blocksize
> - Writes:2GiB/s with large folios vs 1.6GiB/s without folios for 1MB bs
>
> We understand that subfolio dirty page tracking is not available for
> writeback cache with large folios. However this is not a blocker for

The buffered write and writeback paths in fuse go through iomap which
tracks subfolio dirty state.

> GCSFuse and similar cloud/network-based filesystems for the following
> reasons:
>
> 1. We generally recommend applications to use larger io sizes (>1MB)
>    for writes because of the latency involved with the network calls.
> 2. Random writes & small overwrites are also not recommended for cloud
>    based filesystems.
> 3. Beneficial when write back cache is explicitly disabled. Incase of
>    GCSFuse, write back cache is disabled for different other reasons.
>
> Providing these controls allow individual filesystems to explicitly opt
> into large folios once they evaluate their specific workload patterns.

Could you explain the use case of this granularity? The page cache
already adjusts folio size adaptively (eg small/random i/o still has
small orders, high-order allocations fall back gracefully to
lower-order allocations under memory pressure, etc) so it's a bit
unclear to me why a tunable would be needed. It also won't enforce the
order for any inodes that are already in the cache.

There's a patch to enable large folios by default [1] and the
benchmark numbers showed improvements all around, so I don't think
this would be something individual filesystems would have to
explicitly opt into. Does the change in [1] suffice for your use case?

Thanks,
Joanne

[1] https://lore.kernel.org/fuse-devel/20260624012132.1719941-1-joannelkoong@xxxxxxxxx/