Re: [PATCH v2] fuse: allow larger read requests by setting bdi->io_pages

[Miklos Szeredi]

On Tue, 23 Jun 2026 at 02:42, Jim Harris <jim.harris@xxxxxxxxxx> wrote:
>
> A FUSE server that advertises a large max_pages and max_write (e.g.
> max_pages=256, max_write=1MB) cannot currently obtain matching
> FUSE_READ request sizes from the kernel.  Buffered sequential writes
> arrive at the server at the negotiated max_write size, but a large
> buffered read() is split into several smaller FUSE_READ requests.
>
> For a buffered read, filemap_get_pages() -> page_cache_sync_ra() sizes
> the read against ractl_max_pages():
>
>         max_pages = ractl->ra->ra_pages;
>         if (req_size > max_pages && bdi->io_pages > max_pages)
>                 max_pages = min(req_size, bdi->io_pages);
>
> fuse leaves bdi->io_pages at the default VM_READAHEAD_PAGES (128KB), so
> a 1MB read() (req_size = 256 pages) is clamped to the readahead window
> (128KB, or 256KB for POSIX_FADV_SEQUENTIAL), producing four 256KB
> FUSE_READ round-trips instead of one.
>
> Set bdi->io_pages to fc->max_pages after feature negotiation.  As the
> code above shows, io_pages only raises the limit when the request size
> already exceeds the readahead window, so it enlarges explicitly
> requested reads without enlarging the speculative readahead window.
> This avoids increasing speculative page-cache readahead on behalf of
> an unprivileged server.  NFS does the same, setting io_pages from
> rpages while leaving ra_pages at the default.
>
> fc->max_pages is already bounded by fc->max_pages_limit (and, for
> virtio-fs, by the virtqueue descriptor count), so io_pages inherits
> the same bound.
>
> Suggested-by: Joanne Koong <joannelkoong@xxxxxxxxx>
> Signed-off-by: Jim Harris <jim.harris@xxxxxxxxxx>
> Assisted-by: Cursor:claude-opus-4.8

Applied, thanks.

Miklos