Linux 7.4 enables large folios to accelerate FUSE filesystems
The Linux 7.4 kernel is preparing to enable large folios for FUSE, grouping multiple contiguous physical pages into a single folio to cut the overhead of user-space filesystems. The gains show up on cold reads, as long as the machine is not under memory pressure.
September 29, 2026. Phoronix’s Michael Larabel reports that the patch enabling large folios for FUSE has landed in the for-next branch and is expected to be merged for Linux 7.4. September 2026. The series follows the FUSE improvements already merged into Linux 7.3 for user-space filesystems. Late 2026. Linux 7.4 is a candidate for this year’s LTS kernel if 7.3 is not selected. Why it matters: FUSE filesystems — sshfs, rclone mounts, AppImage, gocryptfs — have always paid a performance tax, and large folios claw back a measurable chunk of it on large transfers.
What a large folio is
A folio has been the kernel’s memory-management unit since the 5.16 series: it groups one or more contiguous physical pages under a single header, where the old model juggled each struct page on its own. A large folio is simply a folio that aggregates several pages — typically 16 KB, 32 KB, or more, depending on the base page size.
The payoff is mechanical. Moving 256 KB as 64 pages of 4 KB forces the kernel to pay the management cost — locks, reference counts, page-cache entries — 64 times. The same amount as a single 256 KB folio pays it once. On the kernel’s hot paths, that difference translates directly into CPU cycles saved and better data locality.
The mechanism is already in production on native filesystems like XFS, ext4, and btrfs. Enabling it for FUSE means extending a proven lever to a class of filesystems that had been shut out of it.
The conversion from struct page to folios is one of the longest-running projects in the memory subsystem. Begun around 2020 under the lead of Matthew Wilcox, it has migrated the page cache, I/O, and filesystems one page at a time. Each conversion removes a conditional branch and a dereference from a hot path, and it is that accumulation of micro-gains that finally shows up in an FIO run. Enabling it for FUSE is one more step in that project, not an isolated novelty.
The FUSE tax, and why large folios lighten it
FUSE, short for Filesystem in Userspace, moves a filesystem’s logic out of the kernel and into a user-space process. That is what makes sshfs, rclone’s cloud mounts, the portable AppImage format, and gocryptfs’s transparent encryption possible: writing a filesystem becomes a library concern, with no kernel module to compile and no risk of a kernel panic.
The price is a round trip between kernel and user space for every operation, with data copied across the boundary. Each FUSE request crosses that bridge, and the smaller and more numerous the requests, the heavier the overhead. Large folios attack exactly this symptom: by grouping several contiguous pages, they shrink the number of units that must cross over, cutting both the number of traversals and the pressure on the kernel-to-user exchange layer.
The FUSE patch does not enable large folios in every case. The condition is explicit: large folios are used when the system is not under memory pressure. Under tension, FUSE falls back to single pages, where fine granularity remains the better trade-off for recycling memory precisely.
The passthrough_hp benchmark deserves a word of context. Since the arrival of passthrough mode in libfuse, some read operations can be served by the kernel without a round trip into user space once the file is already open — the user-space process only sees the metadata. High-performance mode pushes that logic further. Large folios complete the picture: where passthrough cuts the number of round trips, large folios cut the number of pages to manage for each remaining transfer.
The numbers: gains on cold reads, outside memory pressure
Phoronix validated the patch on passthrough_hp, libfuse’s high-performance passthrough mode, using a buffered FIO benchmark. Two backing stores were tested: a tmpfs backing, and an XFS backing on NVMe, with the focus on cold reads — the case where data is not yet cached and page management costs the most.
The published result describes “very nice” gains on both configurations, on top of the other FUSE optimizations accumulated in recent months. That is consistent with the mechanics: cold reads are precisely the scenario where per-page overhead dominates, because each page must be allocated, filled, and indexed separately before it reaches the cache.
The wider context strengthens the picture. Linux 7.3 already received its round of FUSE improvements, and a separate optimization prepared for Linux 7.4 speeds up opening files for reading by about 39%. The direction is clear: maintainers are methodically attacking the points where FUSE’s user-to-kernel overhead costs the most.
What this changes in practice
For the user, there is nothing to configure: the activation is transparent and kernel-driven, with an automatic fallback under memory pressure. Anyone mounting remote volumes through sshfs or rclone, running AppImage applications, or reading large media on a gocryptfs filesystem will feel the effect first on big sequential transfers — the first bytes of a large file, backups, and user-space database reads.
Two caveats are worth keeping in mind. First, these gains concern FUSE only: native filesystems have enjoyed large folios for a long time, and an sshfs mount will remain structurally slower than a kernel mount — the user-space boundary does not go away. Second, the benefit depends on the workload: small random reads, where contiguity does not exist, have nothing to aggregate and will see almost no change.
The practical takeaway is proportional. A media server streaming large files from an rclone-mounted cloud bucket, or a workstation opening a multi-gigabyte AppImage, exercises exactly the cold sequential reads that benefit most — and does so with no sysctl, no mount flag, and no rebuild of the userspace daemon. The kernel decides when a large folio is worth it and backs off when memory gets tight, which is the kind of default that ships without an admin ever noticing it.
The stakes go beyond comfort. If Linux 7.4 becomes the LTS of 2026, this FUSE improvement will be frozen into enterprise and distribution kernels for years. The work done now on large-folio handling will therefore benefit a very broad user base, far beyond the circle of exotic-filesystem enthusiasts.
Verdict
If you move large files over a FUSE mount — rclone backups, big sshfs media, user-space databases — plan the migration to Linux 7.4 when it ships: the cold-read gains arrive with zero configuration, and the memory-pressure fallback removes the main regression risk. If your workload is small random reads, do not rush anything: large folios have nothing to aggregate, and your bottleneck will remain the kernel-to-user crossing itself. And if you push kernels into production, test the libfuse passthrough_hp patch with buffered reads on your own volumes before rolling it out, watching memory latency as well as throughput — that is the one documented scenario, and it is where validation belongs.
References
- Phoronix — Large Folios Able To Deliver Big Performance Gains For FUSE With Linux 7.4 (Michael Larabel, September 29, 2026)
- Phoronix — Simple Optimization For Linux 7.4 Can Open Files For Reading ~39% Faster (Michael Larabel, September 2026)
- Phoronix — FUSE Improvements Head Into Linux 7.3 (Michael Larabel, September 2026)
- LWN.net — Kernel prepatch 7.3-rc5 (September 27, 2026)