deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

Linux 7.4 makes FAT32 fallocate up to 265x faster by dropping a six-line loop

A tiny kernel patch in Linux 7.4 lets the FAT32 driver allocate clusters in bulk instead of one at a time, cutting fallocate on synchronous mounts from 92 seconds to 0.3 seconds.

Linux 7.4 makes FAT32 fallocate up to 265x faster by dropping a six-line loop

A six-line loop removed, four lines added

Linux 7.4 includes a small change to the FAT filesystem driver that makes space preallocation on FAT32 volumes up to 265 times faster. According to a dev.to write-up originally published on Joho no Todai, the gain comes from a patch series that removes a while loop in fs/fat/file.c: six lines deleted, four added.

The old fallocate code allocated disk clusters one at a time, looping while clusters remained and calling fat_add_clusters(inode, 1) on each pass. The new code makes a single call, fat_add_clusters(inode, nr_cluster), handing the driver the full cluster count in one go. Matheus Alves de Almeida of the Federal University of Rio Grande do Sul in Brazil posted the three-patch series on October 12; the first two patches extend fat_add_clusters() to handle multiple clusters, and the third rewrites the caller to use it.

The per-cluster loop mattered because FAT32 manages space in clusters whose size is fixed at formatting, anywhere from 512 bytes to tens of kilobytes. Preallocating 256MiB on a volume with 512-byte clusters means working through roughly 524,000 of them.

Why synchronous mounts gain the most

The benchmark figures come from the patch's commit message, measured under QEMU/KVM with virtio-blk and cache=none. The headline case, fallocate on sixteen 16MiB files with 4,096-byte clusters on a synchronous mount, fell from 92.489 seconds to 0.348 seconds, a 265.4x speedup.

The mechanism is straightforward. On synchronous mounts, every cluster allocation forced a synchronous write of the updated FAT table to disk. Allocating tens of thousands of clusters therefore meant tens of thousands of blocking metadata writes. The new code batches FAT updates, so metadata reaches the storage device far less often.

Asynchronous mounts improve as well, just less dramatically. The dev.to article cites a 13.2x gain, from 2.328 seconds down to 0.175 seconds, when allocating 256MiB with 512-byte clusters, and even the weakest measured case, 128 files of 16KiB without sync, came in 5.3x faster. Fewer metadata operations pay off even when no forced sync is involved.

What the change does not cover

The speedup is limited to fallocate, and specifically its FALLOC_FL_KEEP_SIZE path, which reserves blocks without changing the file's reported size. Regular reads and writes, including copies made with cp or dd, follow other code paths and gain nothing directly. FAT32 transfers to a USB stick will not suddenly run hundreds of times faster.

The real beneficiaries are programs that preallocate space, such as databases, virtual disk image creation and some backup tools, and above all embedded systems that write to slow flash media on synchronously mounted volumes.

FAT32 is still everywhere in 2026: USB sticks, SD cards, digital camera media, and the EFI system partition of UEFI machines, kept alive largely because Windows, macOS and Linux all read and write it.

Why it matters

Beyond the raw numbers, the patch is a reminder of how much performance can hide in unglamorous code. FAT maintainer OGAWA Hirofumi gave an Acked-by to all three patches, and they landed for Linux 7.4-rc1 on October 25 through Andrew Morton's non-MM pull request, which carried 134 patches in total. According to the source, the same batch included FAT fixes for a data-region calculation overflow on 32-bit systems and for rolling back directory entries when file creation fails.

For anyone running Linux on hardware that mounts storage synchronously, a common setup on embedded devices with slow flash, a minute and a half of waiting shrinks to a fraction of a second because someone finally questioned a loop that had been quietly burning time for years.

  • #linux-kernel
  • #fat32
  • #filesystems
  • #performance
  • #open-source

Related posts