Two days ago the Linux kernel absorbed another set of changes that will matter to anyone who moves large files onto USB sticks or SD cards. The exFAT driver, long a practical necessity for cross-platform removable storage, has completed its conversion to the kernel’s modern iomap framework. The work arrived inside the merge window for what will become Linux 7.2, and the immediate effect is better performance on everyday tasks.
Namjae Jeon submitted the pull request. Jeon also maintains the in-kernel NTFS driver. His latest batch of exFAT patches replaces the driver’s older buffer-head code paths with calls to iomap for buffered I/O, direct I/O, and the llseek operations that locate holes and data in sparse files. Phoronix reported the merge on June 20, 2026, noting that the change delivers “some very nice performance gains.” Those gains come without any single dramatic benchmark number attached yet. They arise instead from removing duplicated address-space operations and letting exFAT inherit optimizations already present in ext4, XFS and parts of btrfs.
But the real story runs deeper. The buffer-head mechanism the driver previously relied on dates to an era of 512-byte blocks and mechanical disks. Flash storage works in larger pages. Large folios, which treat contiguous memory regions as single units, reduce metadata overhead and locking during sequential reads and writes. Kernel documentation states plainly that large-folio support exists only through iomap, with no plans to carry it back to the older path. By moving to iomap, exFAT stops sitting on the outside of storage improvements that land elsewhere in the kernel. It joins the main table.
Users will notice the difference when they copy big video files or disk images to high-capacity SD cards. The SD Association requires exFAT for SDXC and SDUC media larger than 32 gigabytes. That mandate, combined with native support across Windows, macOS, Linux, iOS and Android, keeps the format dominant for portable media despite its Microsoft origins. Transfers that once felt sluggish on large partitions should now run quicker. Cleaner internal code also reduces the chance of subtle bugs.
The pull request did not stop at the iomap conversion. It carried a collection of fixes and smaller code cleanups that improve overall stability. Jeon has steadily tightened the driver since native exFAT support landed in kernel 5.4 in late 2019. A 2025 patch addressed an infinite loop on malformed media that could stall directory operations. Earlier work in the 6.18 cycle cut allocation bitmap loading time dramatically. One test showed roughly 16.5 times faster mount behavior on large volumes that used small cluster sizes. Phoronix covered that optimization last October. The pattern is clear: incremental but persistent refinement rather than one-off overhauls.
That steady pace matters. Many Linux users rely on exFAT every day without thinking about the file system at all. Plug in a thumb drive, copy files, unplug. The driver must simply work, and it must work fast enough that the hardware feels like the bottleneck rather than the software. For years the in-kernel exFAT code lagged behind the polished implementations in Windows and even some third-party Linux drivers. The iomap move erases one of the last major architectural gaps.
Timing adds weight to the change. Linus Torvalds released Linux 7.1 just over a week ago. The merge window for 7.2 opened shortly afterward on June 14. Jeon’s exFAT patches landed inside that window on June 20. The first release candidate is scheduled for June 28, with a stable version expected in late August. Distributors will begin picking up the code soon after. Server administrators may wait for point releases, but desktop users and embedded developers who work with removable media will see the benefits once their favored distributions ship the new kernel.
Other storage work landed in the same merge window. The NTFS driver received hardening and fixes from the same maintainer. EXT4 got fast-commit rework and quicker directory hashing. Block-layer updates touched io_uring and NVMe. The exFAT changes sit comfortably alongside them. They form part of a broader effort to modernize every major file system against the demands of solid-state storage and large-memory machines.
Look closer at the technical shift and the advantages multiply. Previous exFAT buffered writes and direct I/O each maintained their own address-space operations. Those paths duplicated effort and created separate surfaces for bugs. Iomap centralizes the mapping from logical file offsets to physical blocks. It replaces per-buffer structures with per-folio bitmaps. The result scales better when the kernel decides to read or write 64-kilobyte or larger chunks instead of 4-kilobyte pages. Fewer locks. Less CPU time spent in overhead. And because iomap already powers the most-used Linux file systems, future optimizations written for it will automatically become available to exFAT.
Yet the change will not feel revolutionary to most users. No flashy new mount options. No sudden doubling of throughput on every workload. Just faster large sequential transfers on the devices people already own. That quiet competence defines much of the kernel’s storage development. The code that runs underneath everyday tasks improves steadily until one day the old complaints simply vanish.
Recent coverage confirms the practical impact. TechTimes highlighted on June 21 that USB and SD card transfers stand to benefit directly. The article noted that the conversion eliminates architectural debt and lets exFAT ride along with kernel-wide storage advances that buffer-head code could never receive. It also reminded readers that the update will not appear in current stable kernels. Early adopters can test it once the first 7.2 release candidate drops at the end of this month.
Discussions on X echoed the same themes. Phoronix’s own post on the story drew comments from users who keep external drives formatted in exFAT precisely because of its broad compatibility. One Linux forum participant called the upcoming kernel version promising for exactly this reason. The conversation stays grounded. No one expects the driver to suddenly outperform native Windows exFAT handling. They simply want it to stop feeling like a second-class citizen.
The broader context reveals why these seemingly small file-system patches keep coming. Removable storage has not disappeared in the age of cloud sync. Photographers still hand off SD cards. Video editors shuttle terabytes on external SSDs. Developers test firmware on USB drives. All of them benefit when Linux handles the format that every other operating system already understands. And when that format stops dragging on modern hardware, the entire experience improves.
So the iomap conversion marks one more step in a longer march. Jeon and other contributors continue to close the gap between what the kernel promises and what users actually feel when they insert a drive. Linux 7.2 will ship with a faster, cleaner exFAT implementation. The code under the hood now matches the hardware it serves. For an industry that measures progress in throughput graphs and bug counts, that counts as real forward movement.
WebProNews is an iEntry Publication