News › performance
By The Linux Camp News, October 29, 2026
The FAT allocation change targets space reservation without increasing file size. Batching removes repeated allocation work, especially on synchronous mounts, but the supplied evidence cannot establish the conditions behind the reported 265× gain.
Phoronix reported on October 29, 2026 that Matheus Alves de Almeida’s FAT allocation changes had merged for Linux 7.4 through Andrew Morton’s non-MM pull request. The primary request targets 7.4-rc1: this is development-cycle coverage, not evidence of a final 7.4 release. The optimization targets preallocation with FALLOC_FL_KEEP_SIZE rather than every FAT32 operation. 1 3 2
FALLOC_FL_KEEP_SIZE reserves disk space without changing the file’s reported size. Previously, the FAT driver handled that reservation through repeated single-cluster allocations. The series lets fat_fallocate() request multiple clusters in one fat_add_clusters() call and batches FAT updates. Removing that repeated work is the source of the improvement; Morton’s summary singles out synchronous mounts as especially affected. 1 2 3
An enabling change removes a fixed allocation-count limit. The allocator had an array of buffer_head entries used to defer synchronization and mirroring, and rejected requests exceeding its cluster limit with BUG(). Processing those buffers in batches allows larger requests without requiring all their deferred work to fit that old limit. 4
For operators, the useful first check is whether an application actually uses KEEP_SIZE preallocation on FAT storage, and whether the mount is synchronous. The operational inference is that space-reservation latency is the relevant measurement to compare, not generic read or write throughput: the documented optimization removes overhead in that specific allocation path. 3
Phoronix attributes gains of up to 265× to Almeida’s work. The cover letter says benchmark results were added to the fallocate commit log, but those results are absent from the supplied packet retrieved October 29, 2026. Hardware, allocation sizes, timings and the exact 265× case therefore cannot be assessed here; the number is a reported result, not an independently reproduced expectation. 1 2
The scope also stops short of broader allocation changes. Almeida explicitly leaves the directory-entry path unchanged and does not implement the separate multi-cluster TODO in inode.c. That work, he says, would require speculative preallocation or an iomap conversion. These boundaries are another reason not to apply the headline multiplier to unrelated FAT workflows. 2