A few lines of code speed up FAT32 by up to 265x in Linux 7.4
A patch of a few lines in the kernel’s FAT driver replaces one-cluster allocations with a single multi-cluster call, for a measured speedup of up to 265x on pre-allocation. Merged into Linux 7.4, it is a reminder that FAT32 is still production-grade on EFI partitions, USB sticks and embedded devices.
Late October 2026. A patch by developer Matheus Alves de Almeida is merged into Linux 7.4 through Andrew Morton’s non-MM pull request. October 29, 2026. Phoronix reports spectacular numbers: up to 265x faster on FAT32 file pre-allocation. A few lines of code explain the gain. FAT32 is not dead — it still carries the EFI partition on almost every machine.
The bottleneck: one cluster at a time
The path in question is FALLOC_FL_KEEP_SIZE, a fallocate flag that pre-allocates disk space for a file without changing its reported size. Hypervisors use it for QEMU images, databases to reserve space, download clients to avoid fragmentation.
Under FAT32, the historical implementation split that pre-allocation into one cluster allocation at a time. For a large file, that means thousands of individual calls, each with its own accounting, locks and metadata writes. The patch changes that: instead of allocating one cluster per call, it allocates multiple clusters in a single call.
# Pre-allocate 1 GB without changing the file's reported size (FALLOC_FL_KEEP_SIZE)
fallocate --keep-size -l 1G image.imgUnder the hood, FAT32 keeps its allocation table — the File Allocation Table — as a linked list: each cluster points to the next. Allocating a file means writing a chain of pointers into that table, and every write forces a re-read and sync of the affected region. By splitting pre-allocation into one-cluster calls, the old code multiplied those table accesses for nothing. The patch groups the chain into a single pass, which explains the size of the gain on a path that looked trivial.
The result is a speedup of up to 265x on the micro-benchmarks published by the developer. The fix touches “a few lines of code” — a reminder that legacy paths can hide enormous bottlenecks.
FAT32 is not a dead filesystem
Many consider FAT32 a relic. That is a mistake. The format remains unavoidable in three specific cases.
The EFI System Partition (ESP), which carries the UEFI bootloader, is FAT32 on almost every machine — Windows, Linux and macOS alike. USB sticks and SD cards are still formatted as FAT32 for compatibility with televisions, consoles, cameras and car radios. And embedded systems and firmwares use it for the simplicity of its implementation.
The filesystem has known limits: 4 GB per file, 8 TB per volume at most with 32 KB clusters, and no journaling — a power cut can corrupt metadata. But those limits did not kill the usage. They simply froze the use cases onto small-capacity media and system partitions.
Where FAT32 came from, and why it won’t leave
FAT32 is not a choice; it is a legacy turned standard. The format appeared with Windows 95 OSR2 in August 1996 to break the 2 GB partition ceiling of FAT16. Its 4 GB per-file limit comes from a 32-bit file-size field in the directory entry: a constraint baked into the format itself.
The logical successor, exFAT (2006), lifts that limit, but adoption is uneven. Older card readers, televisions and car radios do not always read it. The UEFI specification also mandates FAT32 support for the ESP: that is the anchor making the format impossible to remove from new machines, whatever the distribution. The SD card specification tells the same story: FAT32 for cards up to 32 GB (SDHC), exFAT beyond (SDXC).
The result is a format with frozen use cases and a structural constraint: you cannot remove it without breaking UEFI boot, removable-media compatibility and part of the embedded world. It is precisely because FAT32 is unavoidable that its allocation path deserved optimizing.
What the patch changes, and what it does not
The scope of the gain needs to be precise. The patch speeds up the pre-allocation path — not the actual writing of data. A normal file transfer to a USB stick will not see a 265x gain: it is the fallocate --keep-size operation that benefits, when space is reserved up front.
The Linux 7.4 cycle gives a sense of the state of the FAT subsystem. The same cycle saw the NTFS3 driver hardened against corrupted or maliciously crafted volumes, and F2FS gain opt-in multi-grain timestamps. The kernel keeps investing in compatibility filesystems, not out of nostalgia, but because they are load-bearing: the EFI partition alone justifies keeping the FAT driver maintained and fast.
The deeper lesson goes beyond FAT32. A rarely inspected code path — here, cluster allocation — can accumulate enormous inefficiency simply because nobody has re-measured it in years. That is the strongest argument for targeted micro-benchmarks on cold paths.
Who benefits, concretely? Anyone who pre-allocates before writing — QEMU image creation, database files, large downloads seeded onto SD cards or USB drives. The usual caution applies to any allocation-path change: the merge shipped with benchmarks, but filesystem patches of this kind deserve a regression watch. A fallocate --keep-size workload is narrow enough to test in minutes, so run a quick sanity check after upgrading to 7.4 rather than discovering a regression in production.
The fix is a micro-optimization, not a rewrite. It does not change the on-disk format, does not add journaling, and does not touch the 4 GB file ceiling. Its value is symbolic as much as practical: it shows that even the most dated code paths are still measured, and still worth fixing when the measurement says so.
What this says about kernel maintenance
The patch arrived through Andrew Morton’s non-MM pull request, one of the routes by which filesystem and memory fixes reach the kernel. That detail matters: it shows Linux treats compatibility filesystems as first-class citizens, on par with recent hardware drivers.
The 7.4 cycle illustrates this double movement. On one side, performance gains on historical paths — here FAT32, but also a boot-time memory allocator that went from 268 seconds to about 50 milliseconds. On the other, hardening: the NTFS3 driver reinforced against corrupted or maliciously crafted volumes. The kernel does not arbitrate between performance and security: it advances on both fronts, including where nobody is looking.
For system operators, the conclusion is simple: these paths are not abandoned, and kernel upgrades deliver real gains — even on components that looked frozen for twenty years. The lesson in restraint holds for engineering too: the 265x gain came not from a rewrite, but from a measurement and a targeted fix.
Verdict
If you pre-allocate files on FAT32 media — virtual machine images, large files written to SD cards or USB sticks — kernel 7.4 gives you a real gain, and there is nothing to do: the fix is already merged. For everyday use, no action: file transfers and reads do not change, and FAT32 stays what it was — simple, unjournaled, capped at 4 GB per file. If you build embedded systems or system images, take the real lesson: before rewriting a legacy code path, measure it. A few lines can be worth two orders of magnitude. And if you maintain a distribution kernel, this is exactly the kind of performance fix that backports tend to skip in favor of security-only updates: check that it is not dropped. A 265x gain on the wrong branch helps no one.